fix: prevent stale header rules with versioned storage meta#88
Draft
fix: prevent stale header rules with versioned storage meta#88
Conversation
Kirrrusha
requested review from
AndreyTheWeb,
Egorzaa,
JustPilz and
raidenmiro
as code owners
🤖 Pull request artifacts
|
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
13f91af to
1585555
Compare
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
1585555 to
c7d6752
Compare
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
c7d6752 to
92e9ea1
Compare
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
86e0f30 to
386b0d7
Compare
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
5d6b119 to
fae69b7
Compare
- Add retry logic (3 attempts with exponential backoff) for transient
DNR updateDynamicRules errors ("Internal error while updating dynamic rules")
- Re-throw errors from setBrowserHeaders to prevent queue state from updating
when rules fail to apply
- Add detailed diagnostic logging for debugging header toggle issues
…start MV3 service workers are killed by Chrome after ~30 s of inactivity and restarted on demand Dynamic DNR rules persist across SW sessions but neither onStartup nor onInstalled fires on a plain SW restart so stale rules from a previous session eg for headers that were later disabled would stay active — meaning disabled headers kept being injected into requests until the user made a storage change Fix call applyHeadersFromStorageQueue'sw-init' at module load time so every SW restart reconciles DNR state with storage The existing meta/fingerprint deduplication prevents redundant applies when the state has not changed eg when onStartup also fires on browser start Add e2e tests in sw-restartspects that simulate the scenario by injecting a stale DNR rule directly triggering chromeruntimereload and asserting the rule is cleared by sw-init in the new worker session
…romeruntimereload is not usable in launchPersistentContext after calling it Playwright stops tracking the new service worker and the extension URL becomes permanently unreachable Instead the tests now simulate the same apply path applyHeadersFromStorageQueue which sw-init also calls by toggling isPausedV1 in storage This changes the storage fingerprint and forces a genuine apply without needing an actual SW restart Two separate storage writes are serialised via an explicit waitForRulesCount barrier between them to prevent the queue from collapsing both changes into a single apply that would see the original fingerprint Also fixes the storage key the correct key for the paused flag is 'isPausedV1' not 'isPaused'
…y After a plain SW restart (e.g. computer unlock), disabled headers from the previous session remain active as stale DNR dynamic rules until the full sw-init apply completes (~ ms). During that window, disabled headers are still injected into requests. Fix by adding clearDynamicRulesOnSwInit() that removes all dynamic rules immediately on SW boot before the apply reads storage. This reduces the window of incorrect behaviour from ~400 ms to ~5-10 ms (a single getDynamicRules round-trip). If the pre-clear fails, the apply handles cleanup as before — no regression. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… and recovery tests
…When Chrome's dynamic rules API is broken Internal error the session fallback was removing ALL session rules including counteracting ones id >= 1_000_000_000 This left stuck dynamic rules with no counterpart causing disabled headers to be transmitted until the next apply Fix exclude counteracting rule IDs from the session fallback removal list They are cleaned up later in the same apply once stuck rules are reconciled Adds regression test covering the exact scenario from the debug logs
…nteracting session rules to override Chrome's dynamic > session ordering Chrome uses static > dynamic > session - Route onInstalled/onStartup through applyHeadersFromStorageQueue to fix race condition with clearDynamicRulesOnSwInit - Always clean up stale counteracting session rules even when stuckRuleIdslength === 0 - Add retry logic with exponential backoff to clearDynamicRulesOnSwInit - Update tests verify priority2 un-skip stale cleanup test add new cases
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Исправляет Windows-специфичную гонку, когда при переключении вкладок и редактировании заголовков могли применяться устаревшие значения (старый снапшот из storage), перезаписывая актуальную конфигурацию.
Changes
declarativeNetRequest.updateDynamicRules({ removeRuleIds, addRules })одним вызовом, чтобы избежать гонки remove→add.headersConfigMetaV1(seq, монотонныйupdatedAt) и в background пропускаем устаревшие снапшоты, даже если события приходят не по порядку.tabs.onActivatedтолько увеличивала вероятность гонок.updateOverrideHeaders/runtime reload message; обновления теперь идут черезstorage.onChanged.Why this works
На Windows из-за другой латентности и планирования событий чаще происходили перекрывающиеся триггеры применения правил. Версионирование + очередь не позволяют применить старую конфигурацию “после” новой.
Test plan
pnpm test:unitApply skipped (stale meta)), а применения идут последовательно.Notes
seq— best-effort при конкурентных записях;updatedAtпринудительно монотонный и используется как tie-breaker.