[pack] Ensuring JobHost restart suppresion aligns with request lifecycle

[fabiocav]

NOTE: Additional tests and private extension tests pending.

Issue describing the changes in this PR

resolves #10631

This change aligns the restart suspension scope with the request lifecycle, ensuring that a JobHost restart triggered by changes to the functions does not resume before the request is complete, which could otherwise result in its services being disposed prematurely.

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

• Backporting to the in-proc branch is not required
  • Otherwise: Link to backporting PR
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• I have added all required tests (Unit tests, E2E tests)

[kshyju]

Do we know what introduced this issue? Can we add that details to the PR description to help future readers?

[kshyju]

Do we know what introduced this issue? Can we add that details to the PR description to help future readers?

Noticed in-proc backport not required. So, the DI Changes triggered this?

[fabiocav]

Do we know what introduced this issue? Can we add that details to the PR description to help future readers?

The pattern previously in place was fragile, and created an opportunity for services to be consumed after disposal. The flow of events was:

1. API was called
2. Restart suppressed
3. Files written (normally, this would trigger a JobHost restart, the suppression prevented that from happening)
4. Restart resumed, processing pending changes
5. API call returned

When step 4 takes place, the JobHost will be terminated, and the JobHost scoped container will be disposed, causing all associated services to be disposed as well. In in-proc, although there is some evidence of the problem happening, so a backport should probably be considered, the restart didn't occur fast enough (or there were no additional service requests) to impact the response handling, with the changes in the default host, the JobHost disposal is taking place before the response is handled and no longer needs to consume services.

This was a race that was in place from the time that cod was introduced, just not something that was exposed with the previous host.

Hope the above answers the second question as well.

[kshyju]

Did you miss the release notes file?