remote unlock stays refused forever once one undecryptable row is quarantined, and nothing can resolve that row
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start from remote.sh unlock and the reprocess path that reports blocking_remaining after an authentication_failed quarantine. Trace how quarantined rows are stored and whether remote-sync.mjs or sqlite-sync.sh can mark one resolved or excluded. Done when unlock can proceed (or a documented command dismisses the bad row) while ordinary sync start still works. Related: #1284 on the same quarantine/reprocess path.
Written by the indexing model from the issue text.
Description
What happens
In an encrypted team, suppose one pulled row cannot be decrypted (authentication_failed) and is quarantined. From then on, remote.sh unlock fails every time and reports blocking_remaining. Nothing can mark that row as resolved, so unlock stays refused for that team permanently.
Ordinary sync keeps working:
remote.sh sync startstarts the engine.- The one-shot sync cycle imports new messages, and the cursor advances.
What was measured (1.3.0, isolated fixture, disposable server)
- With the undecryptable row still quarantined, a new valid message imports and the cursor advances.
sync startexits 0 and keeps syncing.- Running reprocess directly exits 0 and reports
blocking_remaining=true, without saying anything more. - No command in
remote.sh,remote-sync.mjsorsqlite-sync.shresolves or dismisses a single quarantined row. A search for such a path found none.
Expected
The operator needs a supported way out of this state, for example:
- resolve or dismiss a quarantined row that can never be decrypted, or
- let
unlockproceed with that row explicitly excluded,
so that one bad row does not close the unlock path for good.
Related
- #1284: re-reading quarantined rows after an upgrade. It touches the same quarantine and reprocess path.
- Dominant language
- Shell
- Stars
- 1.5k
- Forks
- 156
- Avg merge
- 14h 56m
- Merged PRs (30d)
- 203
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from fujibee/agmsg
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
[P2] app: peer-message previews pass C0/DEL control bytes to pty_injectPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
Similar issues
-
enhancement security severity:low
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Battle-Cattle/BCUK-Bot-4#959 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Frogging-Family/linux-tkg#1265 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
community-scripts/core#217 ·
Maintainers usually reply within 1 day
-
known-red S3: friction & debt
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
MedakaLang/medaka#4969 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day