Return 500 for requests that timed-out for now

[apurvabhaleMS]

Description

Until we decide on the billing part, let's return 500 for requests that timed-out For Transactions - (This is what we do today as well if the transaction is failed due to any reason)

• If any request failed with 408 (first, midway or last), log the statistics upto where we have collected them with 500 instead of 408
• Do not publish metric notification (No need to worry about the billing as metrics are not published and transaction is rolledback)
• Final status of the transaction would be last failed operation status which is 500 in this case

For Batches -

• Statistics would have an information about how many requests actually failed due to time-out with status code 500
• Publish the metric notification with count of passed + timed-out requests with 500 as status code
• Final status of the batch is always 200

Related issues

Addresses AB119603

Testing

2. .

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• [ ] CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)

[apurvabhaleMS]

Synced offline and decided that this change is not needed. FHIR server would return 408 for requests that timed out