Time Out Error During Bulk Update via FMC API Despite Successful Task Execution

[isrferna]

When attempting to bulk update several objects on the FMC through the API, the task encounters an error and fails. The following message is returned:

  msg: 'Server returned an error trying to execute updateMultipleAccessRule operation. Status code: 500. Server response: The read operation timed out'

Despite this error message, it appears that the FMC has actually completed the task as expected."

For example, the following task is intended to disable 1000 rules:

- name: Disable zero hit rules
  cisco.fmcansible.fmc_configuration:
    operation: "updateMultipleAccessRule"
    path_params:
      domainUUID: "{{ domain_uuid }}"
      containerUUID: "{{ container_uuid }}"
    data: "{{ zero_hit_rules }}"
    query_params:
      bulk: true
      partialUpdate: true

Below is an example of the zero_hit_rules:

zero_hit_rules = [
  {
    "action": "ALLOW",
    "enabled": False,
    "id": "005056A4-EF34-0ed3-0000-000268442597"
  },
  {
    "action": "ALLOW",
    "enabled": False,
    "id": "005056A4-EF34-0ed3-0000-000268442598"
  },
  {
    "action": "ALLOW",
    "enabled": False,
    "id": "005056A4-EF34-0ed3-0000-000268442599"
  },
   # ... (more parameters may exist but are omitted for document purposes)
]

The task to disable zero hit rules is executed correctly by the FMC, but the playbook fails, returning the mentioned error.

Increasing the timeout in the line below fixes the problem described in this issue: https://github.com/CiscoDevNet/FMCAnsible/blob/940a47531ff9b668d72fa36440a7b7d36c8b4225/plugins/httpapi/client.py#L87

It would be nice to be able to pass as a parameter the value of the timeout, something like this:

- name: Disable zero hit rules
  cisco.fmcansible.fmc_configuration:
    operation: "updateMultipleAccessRule"
    path_params:
      domainUUID: "{{ domain_uuid }}"
      containerUUID: "{{ container_uuid }}"
    data: "{{ zero_hit_rules }}"
    query_params:
      bulk: true
      partialUpdate: true
   single_request_timeout: 30

[xibriz]

Seems related to #53