-
Notifications
You must be signed in to change notification settings - Fork 316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: "Illegal invocation" in service-worker #6
fix: "Illegal invocation" in service-worker #6
Conversation
Dear @3cL1p5e7, This repository does not accept external contributions yet. We are therefore closing this Pull Request, thank you for your understanding. — The DFINITY Foundation |
1 similar comment
Dear @3cL1p5e7, This repository does not accept external contributions yet. We are therefore closing this Pull Request, thank you for your understanding. — The DFINITY Foundation |
Dear @3cL1p5e7, This repository does not accept external contributions yet. We are therefore closing this Pull Request, thank you for your understanding. — The DFINITY Foundation |
1 similar comment
Dear @3cL1p5e7, This repository does not accept external contributions yet. We are therefore closing this Pull Request, thank you for your understanding. — The DFINITY Foundation |
test(registry): CRP-943: Fix delete subnet test Change the order in which system subnets are deleted in the `test_subnet_is_only_deleted_when_appropriate` test. The test flow is the following: 1. Create three subnets (two system subnets and one application subnet) 2. Verify that deleting a non-existent subnet fails 3. Verify that deleting the (hard-coded) NNS system subnet fails (no subnet with the mainnet NNS subnet ID exists in the test) 4. Verify that deleting the only system subnet fails 5. Verify that deleting the application subnet succeeds 6. Verify that deleting the second system subnet succeeds There are two issues in the test: - At step #4, there are two system subnets, so deleting either one should succeed - Currently, the deletion of the first system subnet fails at step #4 because the `crypto_threshold_signing_public_key` and `catch_up_package_contents` of that subnet is missing: `2024-01-09 16:31:05.727480874 UTC: [Canister rwlgt-iiaaa-aaaaa-aaaaa-cai] Panicked at '[Registry] Verification of the mutation type failed with the following errors: [Registry Canister Error. Msg: Key not present: catch_up_package_contents_ya35z-hhham-aaaaa-aaaap-yai, Registry Canister Error. Msg: Key not present: crypto_threshold_signing_public_key_ya35z-hhham-aaaaa-aaaap-yai].', rs/registry/canister/src/registry.rs:293:13` The reason why the system subnet deletion currently fails in step #4, but succeeds for the other system subnet in step #6, is because the first subnet is created in `invariant_compliant_mutation_as_atomic_req` which does not set the `crypto_threshold_signing_public_key` or `catch_up_package_contents` for the subnet, but the subsequently created second system subnet does have the `crypto_threshold_signing_public_key` and `catch_up_package_contents` set. The (temporary) fix in this MR does the following: - At step #4, verify that deleting the second system subnet succeeds - At step #6, verify that deleting the first (and now only) system subnet fails A more comprehensive fix that also sets `crypto_threshold_signing_public_key` and `catch_up_package_contents` for the first system subnet will follow in [a subsequent MR](https://gitlab.com/dfinity-lab/public/ic/-/merge_requests/17063). See merge request dfinity-lab/public/ic!17062
This is fix of error message
Failed to fetch response: TypeError: Failed to execute ‘fetch’ on ‘WorkerGlobalScope’: Illegal invocation
while using service-worker in browser.Found, solved and tested in this forum topic
To solve the problem you can accept current PR or accept another PR for agent-js and update dependencies here