fix: prevent stale header rules with versioned storage meta#88
Open
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
92e9ea1 to
386a76a
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
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
386a76a to
3c192ee
Compare
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
4b9e608 to
f564bb9
Compare
…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'
Kirrrusha
force-pushed
the
fix/update-request-with-tab-windows
branch
from
1148fb8 to
6813c3a
Compare
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.