{"version":"2.1.278","anchor":"request-latches-class-reworked-from-two-maps-to-scalar-per-s","canonical_anchor":"request-latches-class-reworked-from-two-maps-to-scalar-per-s","heading":"Request-latches class reworked from two Maps to scalar per-session fields","tier":"internal","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.278\/e\/request-latches-class-reworked-from-two-maps-to-scalar-per-s","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.278","markdown":"### Request-latches class reworked from two Maps to scalar per-session fields\n\nInternal per-session request-latch storage was restructured from two maps to individual fields\n\n**Unclear.** The finding does not explain what behavioral difference, if any, this restructuring produces.\n\n**What**\n\nThe internal object that tracks per-session request state (exposed as `host.requestLatches`) changed how it stores some of its data. Two fields that used to be Maps (key-value lookup structures) are now a plain boolean and two new placeholder fields, alongside other existing maps used for different purposes. This structure backs several internal checks, including ones related to server classifier fallback choices and observed gateways.\n\n**Why**\n\nThis is an internal data-structure change with no direct user-facing effect described, but it underlies features like gateway detection and classifier fallback handling mentioned elsewhere in this release.\n\n- Area: Elsewhere\n- Names: `host.requestLatches`\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}