Now that users can specify buffer sizes as a part of the class constructor, we need to dynamically respond to the buffer size being too small to hold the response xml.
:pager: Implementation Details
At the C code level, if the failing request is detected, a new buffer is allocated large enough for the remaining response and the request is re-driven. If the buffer would need to be larger than the maximum tolerable size for our constructor, we fail and surface the error as a DownstreamFatalError with IRRSMO00's return and reason codes.
:clipboard: Is there a test case?
Since this re-drive is done at the c level, there are no applicable unit tests available. A function test could be added, but we would need confirmation that the environment is appropriate for the test (a command and buffer size must be chosen that we KNOW would fail prior to this feature which may differ dependent on the environment and authority bestowed to pyRACF).
On our test system, I ran two tests. One with setropts_admin.list_racf_options with a buffer specified at 10000 bytes (the minimum) which failed before the added code and now succeeds, and one with resource_admin.extract("*","FACILITY) with the default 16KB buffer which failed and now succeeds.
:bulb: Issue Reference
Issue: #71
:computer: What does this address?
Now that users can specify buffer sizes as a part of the class constructor, we need to dynamically respond to the buffer size being too small to hold the response xml.
:pager: Implementation Details
At the C code level, if the failing request is detected, a new buffer is allocated large enough for the remaining response and the request is re-driven. If the buffer would need to be larger than the maximum tolerable size for our constructor, we fail and surface the error as a DownstreamFatalError with IRRSMO00's return and reason codes.
:clipboard: Is there a test case?
Since this re-drive is done at the c level, there are no applicable unit tests available. A function test could be added, but we would need confirmation that the environment is appropriate for the test (a command and buffer size must be chosen that we KNOW would fail prior to this feature which may differ dependent on the environment and authority bestowed to pyRACF).
On our test system, I ran two tests. One with setropts_admin.list_racf_options with a buffer specified at 10000 bytes (the minimum) which failed before the added code and now succeeds, and one with resource_admin.extract("*","FACILITY) with the default 16KB buffer which failed and now succeeds.