Poll Lanes: one independent Poll stream per Site, replacing the shared pace #101

New Issue

2026-08-16T11:28:12+07:00

sulthan commented

2026-08-16 11:28:12 +07:00

Blocked by: #98

Problem Statement

As a Reader growing my Library, my Series stop being checked every hour long before I notice it. The backend promises each Series a Poll once an hour, but the machinery underneath cannot deliver that past about 84 Series, and it fails silently — nothing logs, nothing warns, the Latest Chapter just quietly gets older.

The cause is a single shared pace. Every Poll of every Site waits behind one 20-second gap, so the whole backend can issue at most 180 Polls an hour no matter how the batch size or wake interval are set. I have roughly 60 Series today and expect several hundred, possibly a thousand. At 250 Series each one is Polled about every three hours; at 1000, about every twelve.

Two more things make it worse. Browser Sites rest for six hours rather than one, so a third of my Library is deliberately stale. And when a Site refuses — which comix, kagane and novelfull all do behind a Cloudflare challenge — each refusal burns the full challenge timeout, so one hostile Site can eat most of an hour of the shared budget and push every other Site's Polls out of the way.

Solution

Give every Site its own Poll Lane: an independent stream of Polls with its own pace and its own rest time, running at the same time as every other Site's.

The pace is per Site, so a slow or refusing Site cannot hold up the other five, and the ceiling grows with the number of Sites rather than being one shared number. Each Lane's gap defaults to ten seconds — the strictest rate rule a free-plan Site can even express is one request per ten seconds — and shortens automatically when a Site holds enough Series that ten seconds cannot fit them all in the hour. It never goes below one second, and reaching that floor logs a warning naming the Site, so the hour becomes a promise the backend keeps loudly or breaks loudly.

Every Site's rest time becomes one hour, including the three browser Sites. The separate six-hour browser rest time disappears, along with the global wake interval, batch size and shared stagger, which no longer mean anything.

User Stories

As a Reader, I want each of my Series checked about once an hour, so that a New Chapter reaches me the same day it is published.
As a Reader with a thousand Series, I want that hourly promise to still hold, so that growing my Library does not silently degrade it.
As a Reader with comix, kagane and novelfull Series, I want them checked as often as my asura Series, so that a third of my Library is not deliberately six hours behind.
As a Reader, I want a slow Site not to delay a fast one, so that one hostile Site cannot make my whole Library stale.
As a Reader, I want a refusing Site to stop being retried immediately, so that its failures do not consume time that other Sites could use.
As a Reader, I want Series that a refusing Site never got to remain due, so that they are attempted at the next opportunity rather than resting for an hour on a Poll that never happened.
As a Reader running without a browser, I want browser Series left unstamped rather than marked as checked, so that they are Polled the moment a browser appears instead of being an hour stale for nothing.
As a Reader, I want the most-shared Series checked first, so that the Series several people are reading stay the freshest.
As a Reader, I want the longest-unchecked Series checked before more recently checked ones within the same popularity, so that nothing is starved.
As a Reader, I want no Series to jump the queue because of who bookmarked it, so that a Poll stays work done on behalf of the Series rather than on behalf of a Reader.
As a Reader, I want Series whose Bookmarks are all in the finished Lifecycle bucket to be left alone, so that the backend is not pacing itself against work it will never do.
As a Reader, I want a Cover being healed not to slow down chapter checks, so that a large import does not make every Latest Chapter go stale.
As the operator, I want each Site kept under one request per ten seconds by default, so that the backend stays inside the strictest rate rule a free-plan Site could express against it.
As the operator, I want the gap to shorten only as far as the Series count actually requires, so that the backend is never faster than it needs to be.
As the operator, I want a hard floor of one second per Site, so that no growth in my Library can turn the backend into something a Site owner would call a scraper.
As the operator, I want a warning naming the Site whenever its gap is clamped to that floor, so that I find out from the log rather than from a complaint.
As the operator, I want the browser Sites to do their work in one continuous run, so that the remote Chrome wakes once and sleeps once instead of starting all hour.
As the operator, I want a browser Lane to wait for a small group of due Series before waking Chrome, so that one straggler does not start a browser for a single Poll.
As the operator, I want a lone Series that has been waiting too long to wake the browser anyway, so that a Series that drifts out of the group is not starved forever.
As the operator, I want the browser Lanes to stop for the rest of a run when Chrome is unreachable, so that two dozen Series do not each wait out a connection timeout.
As the operator, I want the three browser Sites to share one page at a time, so that the remote Chrome's memory stays inside what has actually been measured on that machine.
As the operator, I want a log line when the browser Sites cannot keep up with the hour, so that the decision to give them more pages is made from a measurement rather than a guess.
As the operator, I want the settings that no longer do anything removed rather than ignored, so that nobody can set a value that silently has no effect.
As the operator, I want the exact environment edit needed at deploy time written down, so that the deployed configuration and the code do not drift.
As a maintainer, I want the rest time and the gap to live in the Site registry beside everything else that describes a Site, so that there is one place a Site is described.
As a maintainer, I want the due query to ask about one Site at a time, so that the query stops carrying parallel lists of Sites and cut-off times.
As a maintainer, I want a written decision record explaining why the rate is computed rather than fixed, so that the next reader understands the ten-second figure came from what a free-plan Site can express.

Implementation Decisions

Poll Lane. The unit of scheduling becomes the Poll Lane, now a glossary term: one Site's own stream of Polls, with its own pace and rest time, unable to slow, block or borrow from another's, and never influenced by a Reader. Every Site has exactly one. All Lanes run concurrently.

Rest time moves to the registry, one hour everywhere. Each Site's registry entry carries its rest time. All six start at one hour. The separate browser rest time and its environment variable are removed, not defaulted. The per-Site structure is deliberately uniform at first: it exists so a single Site can be slowed if it turns hostile, and that intent should be recorded as a comment, since a reader will otherwise ask why the structure exists when every value matches.

Pace. Each Site's registry entry carries a gap, defaulting to ten seconds. The effective gap is the smaller of that and one hour divided by the Site's eligible Series count, with a floor of one second. Eligible means every Series of that Site whose Bookmarks are not all in the finished Lifecycle bucket. Counting all eligible Series rather than only those currently due keeps the pace steady, and specifically avoids computing the fastest possible pace at startup, when everything is due at once — the single worst moment to be fastest.

Reaching the floor is loud. When the computed gap is clamped to one second, log a warning naming the Site, every round. At one request per second against one Site from one address, all day, the backend is ten times over the strictest rule a free-plan Site can express; that is a state the operator must never be in without knowing.

Ordering within a Lane is unchanged. Most-shared Series first, then longest-unchecked. No Reader-derived priority of any kind: shortage is absorbed by the long tail, not by an unlucky Reader. This is already how the due query orders, and it is already the fair answer, because a Poll is work done on behalf of the Series.

Removed settings. The global wake interval, batch size and shared stagger are deleted from the code, the example environment file, the README and the Compose file. They are not kept as ignored values. Their tests go with them. The deploy notes must list the exact environment edit this requires, because a deployed environment file will still carry the old names.

Browser Sites are not selected when the browser is absent. Today they are selected, stamped as checked, and then fail for want of a fetcher, which ages every browser Series by an hour on every tick of a browserless deployment. The fix moves the stamp to after a non-challenge result, so an untried Series keeps its place in the queue. This is a change to the invariant that a Series is stamped before it is fetched, and it needs its own test.

A Site refuses. After two consecutive challenge-held results in one run, that Lane skips its remaining Series for the rest of the run. The two probe Series keep their stamp; the untried ones were never stamped and stay due. The Lane then waits fifteen minutes before attempting that Site again. Counting refusals per Site rather than globally means an unreachable Chrome — which is about all three browser Sites at once — costs two probes per Site before everything stops, which is a small and acceptable extra cost for keeping one counter rule instead of two.

Chrome unreachable. All three browser Lanes stop for that run, not only the Lane that noticed.

Browser wake. A browser Lane starts a run when five or more of its Series are due, or when any one of its Series has been due for fifteen minutes. Below both thresholds it leaves Chrome asleep. Series Polled together become due together, so they naturally stay clustered; these two numbers exist to stop a Series that was added late, or that failed once, from drifting out of the group and waking Chrome on its own.

Browser throughput. One page at a time, shared by all three browser Sites, unchanged. Their combined ceiling is therefore about 360 Polls an hour rather than 1080. That covers the three browser Sites unless they hold more than 360 Series between them. When the shared page cannot keep up, the browser Lanes stretch past the hour and log by how much. Giving each browser Site its own page stays on the shelf until Chrome's memory with three concurrent pages has been measured on the machine that hosts it.

Covers do not consume a Lane's gap. A Series still missing its Cover costs a second request, often to a different host with its own budget. Counting Cover requests against the Series-page gap would mean a large import makes every Latest Chapter go stale. The double cost happens once in a Series's life.

Capacity, for the record. Six Sites at one request per ten seconds is 2160 Polls an hour, against a target of 1000. The hour holds as long as no single Site holds more than 360 Series; past that, the auto-shortening takes over, and past 3600 Series on one Site the floor engages and the hour is formally broken with a warning.

Testing Decisions

A good test here asserts observable scheduling behaviour: which Series were fetched, from which Site, in what order, how far apart, and what was left unstamped. It must not assert how Lanes are structured internally, how many goroutines exist, or what the snapshot type looks like.

Everything lands at the existing Poller seam. The Poller is already constructed in tests with an injected page fetcher, an injected browser fetcher, an injected clock and a real Postgres, and driven a round at a time. Roughly thirty tests already sit there. That seam carries this entire spec, and no new seam is needed. It does require one deterministic entry point equivalent to today's single-round call, so that a test can run exactly one round of every Lane without real time passing.

The behaviours to cover, all at that seam:

A Series is Polled once its rest time has passed and not before.
Two Sites make progress in the same round; a Site that refuses does not stop the other Sites from being Polled.
The effective gap equals the registry default when the Series count is small, and equals one hour divided by the eligible count when it is large.
The gap never goes below one second, and clamping produces a warning naming the Site.
Series whose Bookmarks are all finished do not contribute to the count that sets the gap, and are not Polled.
Ordering within a Lane is most-shared first, then longest-unchecked.
With no browser configured, browser Series are neither fetched nor stamped, and remain due on the following round.
After two challenge-held results from one Site in a run, that Site's remaining Series are not attempted; the two probes are stamped and the remainder are not.
A refusing Site is not retried for fifteen minutes.
An unreachable browser stops all three browser Lanes in that run.
A browser Lane does not start when fewer than five of its Series are due and none has been waiting fifteen minutes; it does start when either condition is met.
A Cover fetch does not delay the next Series-page Poll of that Site.

Prior art for every one of these is in the existing poller tests: the cooldown-across-passes test, the tests that assert a shared Series is fetched once, the tests that assert routing to the browser fetcher, and the table test over the fetchable-Series-URL gate.

Configuration tests follow the existing pattern of asserting that a named environment variable produces a given field value; the tests for the removed settings are deleted rather than adapted.

Out of Scope

Sightings, Reader reputation, and anything that lets a client report defer a Poll. Separate spec, after the dashboard.
The admin dashboard and any visibility of Lane state. Separate spec. Until it lands, Lane state is visible only in the log.
comix's registry entry and its Cover route, which land first in the issue this spec follows.
Giving each browser Site its own page. Blocked on a memory measurement, not on a decision.
Per-Site rest times that actually differ from each other. The structure lands here; nothing yet needs a different number.
Any change to Acquisition, which is triggered by a Reader's first Bookmark and does not queue behind a Lane.
Any change to the wire format, the userscripts, or the web UI's reading surface.

Further Notes

The ten-second default is not arbitrary and should not be tuned away without reading the reasoning. The supporting research established that no Site in this set publishes a crawl delay applicable to a general client — the only delays published name AI crawlers — so the ceiling is the backend's to choose. Ten seconds is the strictest rate rule a free-plan Site can even express, counted per address, which makes it the strongest limit any of these Sites could hold the backend to.

The same research established that a Cloudflare clearance cookie defaults to a thirty-minute lifetime, so any cadence at or above an hour re-solves the challenge on every Poll regardless. Moving the browser Sites from six hours to one therefore does not change whether a challenge is solved, only how many times a day. For comix specifically, combined with the in-tab read shape, the faster cadence is a tenfold traffic reduction rather than an increase.

This spec needs a decision record covering Poll Lanes, the per-Site gap, the automatic shortening and why the floor sits at one second. The floor in particular deserves the reasoning attached: it is an emergency stop rather than a rate, and a Site whose gap is genuinely clamped there is one the operator should be talking to rather than polling.

Blocked by: #98 ## Problem Statement As a Reader growing my Library, my Series stop being checked every hour long before I notice it. The backend promises each Series a Poll once an hour, but the machinery underneath cannot deliver that past about 84 Series, and it fails silently — nothing logs, nothing warns, the Latest Chapter just quietly gets older. The cause is a single shared pace. Every Poll of every Site waits behind one 20-second gap, so the whole backend can issue at most 180 Polls an hour no matter how the batch size or wake interval are set. I have roughly 60 Series today and expect several hundred, possibly a thousand. At 250 Series each one is Polled about every three hours; at 1000, about every twelve. Two more things make it worse. Browser Sites rest for six hours rather than one, so a third of my Library is deliberately stale. And when a Site refuses — which comix, kagane and novelfull all do behind a Cloudflare challenge — each refusal burns the full challenge timeout, so one hostile Site can eat most of an hour of the shared budget and push every other Site's Polls out of the way. ## Solution Give every Site its own Poll Lane: an independent stream of Polls with its own pace and its own rest time, running at the same time as every other Site's. The pace is per Site, so a slow or refusing Site cannot hold up the other five, and the ceiling grows with the number of Sites rather than being one shared number. Each Lane's gap defaults to ten seconds — the strictest rate rule a free-plan Site can even express is one request per ten seconds — and shortens automatically when a Site holds enough Series that ten seconds cannot fit them all in the hour. It never goes below one second, and reaching that floor logs a warning naming the Site, so the hour becomes a promise the backend keeps loudly or breaks loudly. Every Site's rest time becomes one hour, including the three browser Sites. The separate six-hour browser rest time disappears, along with the global wake interval, batch size and shared stagger, which no longer mean anything. ## User Stories 1. As a Reader, I want each of my Series checked about once an hour, so that a New Chapter reaches me the same day it is published. 2. As a Reader with a thousand Series, I want that hourly promise to still hold, so that growing my Library does not silently degrade it. 3. As a Reader with comix, kagane and novelfull Series, I want them checked as often as my asura Series, so that a third of my Library is not deliberately six hours behind. 4. As a Reader, I want a slow Site not to delay a fast one, so that one hostile Site cannot make my whole Library stale. 5. As a Reader, I want a refusing Site to stop being retried immediately, so that its failures do not consume time that other Sites could use. 6. As a Reader, I want Series that a refusing Site never got to remain due, so that they are attempted at the next opportunity rather than resting for an hour on a Poll that never happened. 7. As a Reader running without a browser, I want browser Series left unstamped rather than marked as checked, so that they are Polled the moment a browser appears instead of being an hour stale for nothing. 8. As a Reader, I want the most-shared Series checked first, so that the Series several people are reading stay the freshest. 9. As a Reader, I want the longest-unchecked Series checked before more recently checked ones within the same popularity, so that nothing is starved. 10. As a Reader, I want no Series to jump the queue because of who bookmarked it, so that a Poll stays work done on behalf of the Series rather than on behalf of a Reader. 11. As a Reader, I want Series whose Bookmarks are all in the finished Lifecycle bucket to be left alone, so that the backend is not pacing itself against work it will never do. 12. As a Reader, I want a Cover being healed not to slow down chapter checks, so that a large import does not make every Latest Chapter go stale. 13. As the operator, I want each Site kept under one request per ten seconds by default, so that the backend stays inside the strictest rate rule a free-plan Site could express against it. 14. As the operator, I want the gap to shorten only as far as the Series count actually requires, so that the backend is never faster than it needs to be. 15. As the operator, I want a hard floor of one second per Site, so that no growth in my Library can turn the backend into something a Site owner would call a scraper. 16. As the operator, I want a warning naming the Site whenever its gap is clamped to that floor, so that I find out from the log rather than from a complaint. 17. As the operator, I want the browser Sites to do their work in one continuous run, so that the remote Chrome wakes once and sleeps once instead of starting all hour. 18. As the operator, I want a browser Lane to wait for a small group of due Series before waking Chrome, so that one straggler does not start a browser for a single Poll. 19. As the operator, I want a lone Series that has been waiting too long to wake the browser anyway, so that a Series that drifts out of the group is not starved forever. 20. As the operator, I want the browser Lanes to stop for the rest of a run when Chrome is unreachable, so that two dozen Series do not each wait out a connection timeout. 21. As the operator, I want the three browser Sites to share one page at a time, so that the remote Chrome's memory stays inside what has actually been measured on that machine. 22. As the operator, I want a log line when the browser Sites cannot keep up with the hour, so that the decision to give them more pages is made from a measurement rather than a guess. 23. As the operator, I want the settings that no longer do anything removed rather than ignored, so that nobody can set a value that silently has no effect. 24. As the operator, I want the exact environment edit needed at deploy time written down, so that the deployed configuration and the code do not drift. 25. As a maintainer, I want the rest time and the gap to live in the Site registry beside everything else that describes a Site, so that there is one place a Site is described. 26. As a maintainer, I want the due query to ask about one Site at a time, so that the query stops carrying parallel lists of Sites and cut-off times. 27. As a maintainer, I want a written decision record explaining why the rate is computed rather than fixed, so that the next reader understands the ten-second figure came from what a free-plan Site can express. ## Implementation Decisions **Poll Lane.** The unit of scheduling becomes the Poll Lane, now a glossary term: one Site's own stream of Polls, with its own pace and rest time, unable to slow, block or borrow from another's, and never influenced by a Reader. Every Site has exactly one. All Lanes run concurrently. **Rest time moves to the registry, one hour everywhere.** Each Site's registry entry carries its rest time. All six start at one hour. The separate browser rest time and its environment variable are removed, not defaulted. The per-Site structure is deliberately uniform at first: it exists so a single Site can be slowed if it turns hostile, and that intent should be recorded as a comment, since a reader will otherwise ask why the structure exists when every value matches. **Pace.** Each Site's registry entry carries a gap, defaulting to ten seconds. The effective gap is the smaller of that and one hour divided by the Site's eligible Series count, with a floor of one second. Eligible means every Series of that Site whose Bookmarks are not all in the finished Lifecycle bucket. Counting all eligible Series rather than only those currently due keeps the pace steady, and specifically avoids computing the fastest possible pace at startup, when everything is due at once — the single worst moment to be fastest. **Reaching the floor is loud.** When the computed gap is clamped to one second, log a warning naming the Site, every round. At one request per second against one Site from one address, all day, the backend is ten times over the strictest rule a free-plan Site can express; that is a state the operator must never be in without knowing. **Ordering within a Lane is unchanged.** Most-shared Series first, then longest-unchecked. No Reader-derived priority of any kind: shortage is absorbed by the long tail, not by an unlucky Reader. This is already how the due query orders, and it is already the fair answer, because a Poll is work done on behalf of the Series. **Removed settings.** The global wake interval, batch size and shared stagger are deleted from the code, the example environment file, the README and the Compose file. They are not kept as ignored values. Their tests go with them. The deploy notes must list the exact environment edit this requires, because a deployed environment file will still carry the old names. **Browser Sites are not selected when the browser is absent.** Today they are selected, stamped as checked, and then fail for want of a fetcher, which ages every browser Series by an hour on every tick of a browserless deployment. The fix moves the stamp to after a non-challenge result, so an untried Series keeps its place in the queue. This is a change to the invariant that a Series is stamped before it is fetched, and it needs its own test. **A Site refuses.** After two consecutive challenge-held results in one run, that Lane skips its remaining Series for the rest of the run. The two probe Series keep their stamp; the untried ones were never stamped and stay due. The Lane then waits fifteen minutes before attempting that Site again. Counting refusals per Site rather than globally means an unreachable Chrome — which is about all three browser Sites at once — costs two probes per Site before everything stops, which is a small and acceptable extra cost for keeping one counter rule instead of two. **Chrome unreachable.** All three browser Lanes stop for that run, not only the Lane that noticed. **Browser wake.** A browser Lane starts a run when five or more of its Series are due, or when any one of its Series has been due for fifteen minutes. Below both thresholds it leaves Chrome asleep. Series Polled together become due together, so they naturally stay clustered; these two numbers exist to stop a Series that was added late, or that failed once, from drifting out of the group and waking Chrome on its own. **Browser throughput.** One page at a time, shared by all three browser Sites, unchanged. Their combined ceiling is therefore about 360 Polls an hour rather than 1080. That covers the three browser Sites unless they hold more than 360 Series between them. When the shared page cannot keep up, the browser Lanes stretch past the hour and log by how much. Giving each browser Site its own page stays on the shelf until Chrome's memory with three concurrent pages has been measured on the machine that hosts it. **Covers do not consume a Lane's gap.** A Series still missing its Cover costs a second request, often to a different host with its own budget. Counting Cover requests against the Series-page gap would mean a large import makes every Latest Chapter go stale. The double cost happens once in a Series's life. **Capacity, for the record.** Six Sites at one request per ten seconds is 2160 Polls an hour, against a target of 1000. The hour holds as long as no single Site holds more than 360 Series; past that, the auto-shortening takes over, and past 3600 Series on one Site the floor engages and the hour is formally broken with a warning. ## Testing Decisions A good test here asserts observable scheduling behaviour: which Series were fetched, from which Site, in what order, how far apart, and what was left unstamped. It must not assert how Lanes are structured internally, how many goroutines exist, or what the snapshot type looks like. **Everything lands at the existing Poller seam.** The Poller is already constructed in tests with an injected page fetcher, an injected browser fetcher, an injected clock and a real Postgres, and driven a round at a time. Roughly thirty tests already sit there. That seam carries this entire spec, and no new seam is needed. It does require one deterministic entry point equivalent to today's single-round call, so that a test can run exactly one round of every Lane without real time passing. The behaviours to cover, all at that seam: - A Series is Polled once its rest time has passed and not before. - Two Sites make progress in the same round; a Site that refuses does not stop the other Sites from being Polled. - The effective gap equals the registry default when the Series count is small, and equals one hour divided by the eligible count when it is large. - The gap never goes below one second, and clamping produces a warning naming the Site. - Series whose Bookmarks are all finished do not contribute to the count that sets the gap, and are not Polled. - Ordering within a Lane is most-shared first, then longest-unchecked. - With no browser configured, browser Series are neither fetched nor stamped, and remain due on the following round. - After two challenge-held results from one Site in a run, that Site's remaining Series are not attempted; the two probes are stamped and the remainder are not. - A refusing Site is not retried for fifteen minutes. - An unreachable browser stops all three browser Lanes in that run. - A browser Lane does not start when fewer than five of its Series are due and none has been waiting fifteen minutes; it does start when either condition is met. - A Cover fetch does not delay the next Series-page Poll of that Site. Prior art for every one of these is in the existing poller tests: the cooldown-across-passes test, the tests that assert a shared Series is fetched once, the tests that assert routing to the browser fetcher, and the table test over the fetchable-Series-URL gate. Configuration tests follow the existing pattern of asserting that a named environment variable produces a given field value; the tests for the removed settings are deleted rather than adapted. ## Out of Scope - Sightings, Reader reputation, and anything that lets a client report defer a Poll. Separate spec, after the dashboard. - The admin dashboard and any visibility of Lane state. Separate spec. Until it lands, Lane state is visible only in the log. - comix's registry entry and its Cover route, which land first in the issue this spec follows. - Giving each browser Site its own page. Blocked on a memory measurement, not on a decision. - Per-Site rest times that actually differ from each other. The structure lands here; nothing yet needs a different number. - Any change to Acquisition, which is triggered by a Reader's first Bookmark and does not queue behind a Lane. - Any change to the wire format, the userscripts, or the web UI's reading surface. ## Further Notes The ten-second default is not arbitrary and should not be tuned away without reading the reasoning. The supporting research established that no Site in this set publishes a crawl delay applicable to a general client — the only delays published name AI crawlers — so the ceiling is the backend's to choose. Ten seconds is the strictest rate rule a free-plan Site can even express, counted per address, which makes it the strongest limit any of these Sites could hold the backend to. The same research established that a Cloudflare clearance cookie defaults to a thirty-minute lifetime, so any cadence at or above an hour re-solves the challenge on every Poll regardless. Moving the browser Sites from six hours to one therefore does not change whether a challenge is solved, only how many times a day. For comix specifically, combined with the in-tab read shape, the faster cadence is a tenfold traffic reduction rather than an increase. This spec needs a decision record covering Poll Lanes, the per-Site gap, the automatic shortening and why the floor sits at one second. The floor in particular deserves the reasoning attached: it is an emergency stop rather than a rate, and a Site whose gap is genuinely clamped there is one the operator should be talking to rather than polling.

sulthan added the enhancement ready-for-agent labels 2026-08-16 11:28:12 +07:00

sulthan referenced this issue

2026-08-16 11:28:19 +07:00

Owner-only admin page: Reader roster plus Poll Lane status #102

sulthan referenced this issue from a commit

2026-08-16 11:32:11 +07:00

docs: add Poll Lane and Sighting to the shared vocabulary

sulthan referenced this issue

2026-08-16 11:32:20 +07:00

docs: add Poll Lane and Sighting to the shared vocabulary #104

sulthan referenced this issue from a commit

2026-08-16 11:42:18 +07:00

docs: add Poll Lane and Sighting to the shared vocabulary (#104)

sulthan commented

2026-08-16 13:47:05 +07:00

Duplicate of #100 — the body is byte-identical (only the issue number and state differ). #100 is closed and shipped on main in 3303a55 ("feat: one Poll Lane per Site, replacing the shared pace", PR #106): per-Site Lanes, registry Rest/Gap, effectiveGap = min(gap, rest/eligible) floored at 1s with a Site-naming warning, refusal backoff, browser wake gate and shared tab, background cover work, removed poll knobs, ADR-0010, DEPLOY.md env edit. Closing as duplicate; reopen if the spec was meant to differ.

Duplicate of #100 — the body is byte-identical (only the issue number and state differ). #100 is closed and shipped on main in 3303a55 ("feat: one Poll Lane per Site, replacing the shared pace", PR #106): per-Site Lanes, registry Rest/Gap, effectiveGap = min(gap, rest/eligible) floored at 1s with a Site-naming warning, refusal backoff, browser wake gate and shared tab, background cover work, removed poll knobs, ADR-0010, DEPLOY.md env edit. Closing as duplicate; reopen if the spec was meant to differ.

sulthan closed this issue

2026-08-16 13:47:05 +07:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sulthan/mangaBookmark#101