fix(printing): a print job asks Windows about its own printer only #50

2026-11-11T05:43:11Z

james.maes commented

2026-11-11 05:43:11 +00:00

A print job asks Windows about its own printer only. Requested by the owner on 2026-11-10 after a review found that one broken unrelated printer could stop all printing.

What was wrong

Every job ran a full printer discovery three times: before it was claimed, after the download, and inside the print helper. A full discovery reads the settings of every queue on the PC, which loads every queue's driver. The status report to the server ran one more every round, and a failure there ended the realtime connection.

A hung driver of an unrelated printer failed every job after 20 seconds.
A crash inside the print helper recorded the job as OUTCOME_UNKNOWN although nothing had reached the spooler.

What changes

Three reads, each with one cost: the full discovery (unchanged; for the inventory and the companion's list), a listing without media (the queue enumeration only), and a lookup of one queue with its media.
Before the claim the worker lists; after the download and before SUBMITTING it looks up the job's own printer; the print helper looks it up again. Queues other than the job's own get no per-queue call on the print path and none before the claim.
A failed inventory read no longer ends the connection: the reason is logged once, nothing is reported to the server (a broken spooler is never reported as an empty inventory), and the inventory already delivered stays in force.

What reaches Windows

For the job's own printer at print time: call for call what it was. The reviewer measured it on the test doubles at both commits.
Example, a label job on a station with three queues: 26 native calls before, 10 after, none to the other two queues.
This is a deliberate change to what reaches Windows on the print path (fewer calls), so it is inside the hardware check on real printers.

What it does not cover (stated in the changelog and the troubleshooting guide)

A dead print server. The queue enumeration, by Microsoft's documentation, opens every remote printer connection; a connection to a print server that is off or unreachable can still stall the listing, the lookup and the print. Changing the enumeration would change what reaches Windows and belongs with the hardware check (audit W70).
After a service restart or reconnect printing waits for one complete inventory, so a driver that hangs every time still stops printing from then on. A follow-up is decided and not built: a queue whose settings cannot be read is reported as present and unusable, each queue read in its own helper (ADR-0004, "About printing").
While the inventory read fails, status and media changes of the healthy printers are not reported to the server, and the companion shows a red service problem with the reason.

What does not change

SUBMITTING is recorded before Windows is asked; FAILED means Windows was never asked; an interrupted submission is OUTCOME_UNKNOWN and is never reprinted automatically. The recheck is still exactly once per job.

Verification

Head 3a7c2e7 on release/2.0 at ebea861.
build/Verify.ps1 passed on that head: 1,174 Core, 1,672 Windows runtime and command line, 360 presentation tests, none failed; Core 100% of 2,311 lines; Windows 88.34%.

Review (independent reviewer, three passes)

198e8fc: 0 blockers, 3 should-fix, 9 nits. Thirty single changes of the reviewer's own; one survived (now caught).
e2b53d5: 0 blockers, 1 should-fix, 4 nits (a log line promised that jobs go on in two states where they do not).
3a7c2e7, the head merged: Verdict on 3a7c2e7: 0 blockers, 0 should-fix, 1 nit.

Not proven here: real hardware

Everything about real Windows is unmeasured: whether the listing loads no driver, how a real hung driver behaves inside a lookup helper, the cost of the extra helper processes, the dead-print-server stall. docs/adr/0003-version-2.md has the plan for the check, which starts by reproducing the stall on the old behaviour and records "defect not reproduced" if no queue on the test PC holds a full discovery. Not run.

🤖 Generated with Claude Code

A print job asks Windows about its own printer only. Requested by the owner on 2026-11-10 after a review found that one broken unrelated printer could stop all printing. **What was wrong** Every job ran a full printer discovery three times: before it was claimed, after the download, and inside the print helper. A full discovery reads the settings of every queue on the PC, which loads every queue's driver. The status report to the server ran one more every round, and a failure there ended the realtime connection. - A hung driver of an unrelated printer failed every job after 20 seconds. - A crash inside the print helper recorded the job as OUTCOME_UNKNOWN although nothing had reached the spooler. **What changes** - Three reads, each with one cost: the full discovery (unchanged; for the inventory and the companion's list), a listing without media (the queue enumeration only), and a lookup of one queue with its media. - Before the claim the worker lists; after the download and before SUBMITTING it looks up the job's own printer; the print helper looks it up again. Queues other than the job's own get no per-queue call on the print path and none before the claim. - A failed inventory read no longer ends the connection: the reason is logged once, nothing is reported to the server (a broken spooler is never reported as an empty inventory), and the inventory already delivered stays in force. **What reaches Windows** - For the job's own printer at print time: call for call what it was. The reviewer measured it on the test doubles at both commits. - Example, a label job on a station with three queues: 26 native calls before, 10 after, none to the other two queues. - This is a deliberate change to what reaches Windows on the print path (fewer calls), so it is inside the hardware check on real printers. **What it does not cover (stated in the changelog and the troubleshooting guide)** - **A dead print server.** The queue enumeration, by Microsoft's documentation, opens every remote printer connection; a connection to a print server that is off or unreachable can still stall the listing, the lookup and the print. Changing the enumeration would change what reaches Windows and belongs with the hardware check (audit W70). - **After a service restart or reconnect** printing waits for one complete inventory, so a driver that hangs every time still stops printing from then on. A follow-up is decided and not built: a queue whose settings cannot be read is reported as present and unusable, each queue read in its own helper (ADR-0004, "About printing"). - While the inventory read fails, status and media changes of the healthy printers are not reported to the server, and the companion shows a red service problem with the reason. **What does not change** - SUBMITTING is recorded before Windows is asked; FAILED means Windows was never asked; an interrupted submission is OUTCOME_UNKNOWN and is never reprinted automatically. The recheck is still exactly once per job. **Verification** - Head `3a7c2e7` on `release/2.0` at `ebea861`. - `build/Verify.ps1` passed on that head: 1,174 Core, 1,672 Windows runtime and command line, 360 presentation tests, none failed; Core 100% of 2,311 lines; Windows 88.34%. **Review (independent reviewer, three passes)** - `198e8fc`: `0 blockers, 3 should-fix, 9 nits`. Thirty single changes of the reviewer's own; one survived (now caught). - `e2b53d5`: `0 blockers, 1 should-fix, 4 nits` (a log line promised that jobs go on in two states where they do not). - `3a7c2e7`, the head merged: `Verdict on 3a7c2e7: 0 blockers, 0 should-fix, 1 nit.` **Not proven here: real hardware** Everything about real Windows is unmeasured: whether the listing loads no driver, how a real hung driver behaves inside a lookup helper, the cost of the extra helper processes, the dead-print-server stall. `docs/adr/0003-version-2.md` has the plan for the check, which starts by reproducing the stall on the old behaviour and records "defect not reproduced" if no queue on the test PC holds a full discovery. Not run. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 16 commits 2026-11-11 05:43:11 +00:00

fix(core): a print job reads its own printer and never every printer 29cd0de3cd

A pass of the worker ran the full printer discovery twice: before the claim,
to name the job's printer in the journal, and after the download, to recheck
that printer. The full discovery reads the settings of every printer, so one
printer whose driver hung or failed stopped every pass.

IPrinterBackend now has three reads, named for what they cost the platform:
Discover (the settings of every printer), ListWithoutMedia (the settings of
none) and FindWithMedia (the settings of one). The worker lists before the
claim, in the place the discovery had, so a platform that cannot list its
printers still stops the pass with nothing claimed, the loss of
synchronization during the list still stops before the claim, and the
inventory figure of the timing line keeps its meaning. After the download it
looks up the claimed job's own printer, once, before SUBMITTING is recorded.
Its refusals are unchanged: "Assigned printer or document format is
unavailable." and the media mismatch. The worker no longer calls Discover.

The exposure filter applies its one rule to all three reads: a printer that
is not shared, or has no usable format, is absent. A printer that is not
shared is not asked about at all.

Tests. The fake backend counts each read and has a hook at each. Four
existing tests arranged their fault "at the second discovery"; they now
arrange it at the lookup (or the list), and their assertions are unchanged:
SelectedMediaDriftCannotSpoolAndKnownNativeRefusalIsNotUncertain,
RefusalBeforeNativeSubmissionIsFailedNotUnknown and its sibling with the
same hook, LosingSynchronizationDuringDiscoveryStopsBeforeTheClaim (counts
the list), WorkerTimingLineReportsEachPhaseFromItsClock (advances the clock
in the list and in the lookup). New: the order of one pass with a printer
whose settings cannot be read beside the job's, an idle pass, a platform
that cannot list, and what the lookup can find wrong with the job's printer.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(printing): ask Windows about a job's own queue and leave the others alone 31e78f5dd4

The print helper ran the full discovery before it printed, and so did every
cancellation of a spooled job and every test print. The full discovery opens
every queue and asks its driver for its settings, so a queue the job was not
for could hang or fail the print, after SUBMITTING was recorded.

WindowsPrinters has the three reads over one enumeration and one mapping:
Discover is the two enumeration calls and the settings read of every queue
that can print unattended, as before, call for call; ListWithoutMedia is the
two enumeration calls and nothing else; FindWithMedia is the two enumeration
calls and the settings read of the queue whose identifier matches. The
identifier of each queue is worked out from its name, without a native call.
Two queues with one identifier are refused before either is read.

PrintFileAsync looks up the job's queue with FindWithMedia. For that queue
the calls, their arguments and their order are what they were, including the
settings read before the document, so the call lists the existing tests pin
for a one-queue station are untouched. Queues other than the job's own get
no call. A job whose queue is gone fails with the same error and message as
before; the one existing test for it expected the other queue's settings to
have been read first and now expects the enumeration alone.

The print helper has an operation for each new read, list-without-media and
find-with-media, each with the 20 second limit and the failure handling of
discover. The queue to find travels as its identifier. The service starts no
helper for text that is not 24 hexadecimal digits in lower case (it names no
queue, so it reads as absent), and the helper refuses such a request before
it asks the printers anything. The service refuses an answer that holds a
queue it did not ask for, or more than one.

The profile wrapper adds the operator's display name, description and
location in all three reads: the worker names a job's printer in the journal
from the list.

The operator's and the server's cancellation of a spooled job, and the test
print, need a queue's name or formats and nothing else, and take them from
the list. Their LINQ queries, and with them their failures and messages, are
unchanged.

The fixture helper's queue has an identifier in the real form, because the
helper loop refuses any other, and in hang mode only its full discovery
hangs. The fake Windows can be told that a queue's driver never answers:
every call that names the queue is recorded and then throws.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(runtime): an inventory that cannot be read no longer ends the connection 01dab9917e

The inventory synchronizer runs the full discovery on every status request,
which is every heartbeat round and every wake-up of the lanes. A discovery
that failed (one queue whose driver hangs until the helper's limit is enough)
faulted the synchronizer, which ended the realtime connection, on every
round. The lanes stopped whatever a job itself asked Windows.

A failed read is now caught, cancellation excepted. Nothing is sent, so a
station that cannot be read is never reported as a station with no printers.
The round goes on to reconcile receipts and the connection stays up, so jobs
go on being claimed and printed on the inventory the connection already
delivered. The failure is logged as an error when its reason is not the one
logged last, and its end is logged once.

Not fixed here: dispatch waits for a connection to have delivered an
inventory, so after a restart or a reconnect nothing is claimed until one
full discovery succeeds. The log line says which of the two cases applies.

Tests run a real runtime against the scripted server: jobs keep printing
while the discovery fails; a connection that has delivered no inventory
claims nothing until the printers can be read; a changed reason is logged
again and a cancelled read still ends the connection; cancellations and the
test print work while the discovery fails and are refused as before for a
printer that is gone; the two pipe requests that read the inventory fail
with the reason and the pipe goes on. One test runs the service over the
real Windows rules and a fake Windows with three queues, one of which stops
answering: a job for another queue is claimed, rechecked and spooled, and
the calls made for it name no other queue. For that test the fixture can be
given printers of the test's own, and RecordedPrinters lets the runtime's
threads through one at a time and notes what each read sent.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(printing): record the one-queue change, its limit and what is decided next 17a59d0f1d

CHANGELOG: what a station operator sees. A printer that does not answer no
longer stops jobs for the other printers; the printer list can still be slow
or fail; after a restart or a reconnect nothing prints until the list can be
read once; a spooler that cannot list its printers still stops every job.

ADR-0004, "About printing", dated 2026-11-10: the owner's instruction, the
three reads and where each is used, why the step before the claim stayed
where it was, that the change deliberately reduces what reaches Windows for
other queues and is therefore part of the check on real printers, that the
print helper's calls for the job's own queue are unchanged, the residual
risk in the enumeration, and the per-queue reading of an unreadable queue,
which is decided and not built.

REALTIME, TROUBLESHOOTING, DEVELOPMENT, CLAUDE.md and the threat model
describe the three reads and the helper's five operations. TODO lists the
three open items.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(printing): bring the audit and the records up to the moved one-queue change 9d8da74be0

After the four commits were moved onto release/2.0, which had gained the
audit rows for this defect, the hardware check as a release condition and
pull request 44's account of the check after the download.

Audit: W44 and C25 are closed by the change; W65 is closed for the
connection that ended and stays open for dispatch held after a reconnect or
a restart, with what is decided for it. Four rows for what was found while
fixing W44 and had none: W66 the read of the job's own queue the print
helper still makes and discards, W67 the companion showing a service problem
while jobs print, W68 the pipe serving one request at a time, W69
REFRESH_INVENTORY reading every queue under the command gate. No row is
renumbered or dropped.

ADR-0004 cites pull request 42 (e2ca086) and the rows. ADR-0003 records that
the change is inside both hardware checks and what they have to judge about
it. TODO points at them.

CHANGELOG: this change's entry is first under Unreleased. One sentence of
pull request 44's entry, and two of its sentences in REALTIME, said the
printer is "discovered" once after the download; it is now looked up, and
the reason given for not checking twice no longer names an unrelated queue,
which a lookup does not ask.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(runtime): a round whose inventory read fails still delivers the waiting receipt 077fe18a76

The synchronizer goes on to reconcile receipts after an inventory read
that failed, and nothing pinned it: a change that skipped the receipts of
such a round passed every test of the Windows layer (review of the
one-queue change, S3; the reviewer's change R20).

The new test writes one receipt into the journal while the full discovery
fails and no job is offered. A lane delivers waiting receipts before it
claims, so with no claim made only the synchronizer can deliver this one.
Rounds are set off by a heartbeat on a manual clock, which requests the
status round and wakes no lane. The receipt must reach the server once and
leave the journal's waiting list, with no inventory sent and no claim made.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(printing): a helper answer whose entry is null is refused in the lookup's own words 84e6a46ef5

The lookup of one queue checked that the helper's answer held the queue
asked for and no other, and read each entry's identifier to do it. An
answer whose one entry was the JSON word null made that check fail with a
NullReferenceException. The job still ended FAILED before SUBMITTING, but
with a reason that named nothing (review of the one-queue change, nit 1).
Such an entry is now refused like an answer that names another queue:
"Printer worker returned a printer that was not asked for."

An entry that names the queue and has no formats is not judged at this
boundary, and no test said what becomes of it. Two tests now do. The
lookup returns it as answered, and the exposure filter in front of the
backend fails on it instead of offering it. In the worker, a lookup that
answers with a printer without formats fails the job before SUBMITTING,
with the document downloaded once and the printer never handed it. The
shipped helper writes the formats of every queue, so only an answer that
is not the helper's can look like this; the reason recorded for it is
still the platform's own.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(runtime): the inventory failure line is true for a store failure and for paused dispatch dc1840d04c

The synchronizer's error for an inventory that cannot be read said two
things that are not always so (review of the one-queue change, nit 3).

It blamed a printer's driver. The read it reports is the queues'
settings together with the service's own record of the shared printers
and their names, which comes from the journal, and a failure of either is
caught by the one handler. It also said "Jobs are still claimed" on a
connection that had delivered its inventory, which is false while the
administrator has paused dispatch.

Separating the journal read from the printer read would mean taking the
exposure filter and the profile wrapper apart, so the wording is made
neutral instead. The line now begins "The printer inventory could not be
read", says that this does not stop jobs and that they go on as before,
and names both kinds of cause before the reason. Its end is logged as
"The printer inventory can be read again". Behaviour is unchanged.

Tests: the two existing assertions of the whole line; one with dispatch
paused, where the line is the same and no job is claimed; and one where
the journal's table of shared printers is put out of reach while the
printers answer, where the reason is the journal's failure, the
connection is kept and the end of the failure is logged once. The
troubleshooting row follows the new words.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(printing): the list is Windows' own enumeration, and a dead print server can still stall it 71d6812f9a

The comments, the changelog, docs/REALTIME.md and ADR-0004 said that the
list without media asks no queue anything, so that no queue can slow it
or fail it. That is true of the service's own process and not of Windows
(review of the one-queue change, S1).

All three reads begin with EnumPrinters for local queues and connections
at level 2. Microsoft documents, in the remarks on PRINTER_INFO_4, that
an enumeration at that level performs an OpenPrinter on each remote
connection and waits for RPC to time out when the connection is down,
its server no longer exists or its printer no longer exists. So one
printer connection to a print server that is switched off or unreachable
can still stall the list, the lookup and the print for every printer.
The list runs before every claim with a 20 second limit.

Words only; the enumeration call is not changed, because listing at
another level would change what reaches Windows.

- The code comments now say that this process opens no queue and asks
  no driver, and what the spooler may still do (WindowsPrinters,
  IPrinterBackend, IsolatedPrinterBackend, the print's own comment).
- The changelog entry says a job reads the settings of its own printer
  only, and lists the dead print server first under what a broken
  printer still affects: the fix covers a broken driver on the station
  and does not cover a dead print server.
- docs/REALTIME.md and ADR-0004 state it as a known limit, with what
  happens when Windows waits longer than the limit, and say that it
  rests on Microsoft's documentation and was not measured.
- docs/TROUBLESHOOTING.md has a row for it.

Also in the changelog (nit 4 of the same review): the entry said "one
limit" and listed four; it now points at the list without counting, and
the list adds that while the printer list cannot be read nothing about
any printer, a healthy one included, is reported to the server. ADR-0004
and docs/REALTIME.md say the same. The comment on the print that had a
stranded short line is reflowed (nit 7).

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(audit): rows for the dead print server, unsharing and tests in parts; who decided the wider change 05c7b0c2dd

The audit, after the review of the one-queue change. 123 rows become 126;
W70 to W72 are added, nothing is renumbered and no row is dropped.

- W70 (the review's S1, should-fix): a printer connection to a print
  server that is switched off or unreachable can still stall the list,
  the lookup and the print. Open; the enumeration is deliberately
  unchanged, because listing at another level would change what reaches
  Windows and belongs with the hardware check. The closed rows W44 and
  C25 now point at it.
- W71 (nit 2): unsharing a printer runs the full discovery although it
  needs no list. It was recorded only inside W67, a row about the
  companion's display. Not changed in this round.
- W72 (nit 9): no test goes from the service through the isolated
  backend and a helper process to the real WindowsPrinters over the
  fake Windows, and two queues with one identifier are tested at the
  Windows level only. A test in one piece was not added: the fake
  Windows is in the test assembly, and one job's three reads are three
  helper processes.
- Nit 6: the open rows that cite lines the one-queue change moved carry
  the numbers of that change's tree, and the table's own paragraph says
  so. The review named W45, W46 and W48; W57 to W61 cite the same files
  and are brought up with them, so that one file is not cited at two
  commits. Only numbers changed. Each was matched by its text at
  e2ca086 against the tree.

ADR-0004, "About printing" (nit 5): the owner asked for the fix of the
first finding. Taking the two further places and the design of three
reads into the same change was decided by the integrator on 2026-11-10,
under the owner's standing instruction, after the author found them.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(adr): a hardware check for the one-queue change that can fail 6f8bd5762b

The hardware check as written for the one-queue change could pass
without showing that the fix works (review of that change, S2). Its only
broken queue was one that is paused or whose device is switched off, and
such a queue normally still answers the settings read from the driver's
own data, so the code before the change would have printed there too.
It had no case of a printer connection to a print server.

ADR-0003 now carries the reviewer's nine items as the plan for this
change, under "Hardware check: what it must look at for the one-queue
change". It is marked as a proposal: the owner has not agreed to it and
none of it has been run. The first rule is stated plainly: reproduce the
stall on the old behaviour first, and record "defect not reproduced" if
no queue on the test PC holds a full discovery; a paused queue or a
switched-off printer is not such a case. Item 4 is the connection case
of W70.

What the section already said about approval stands and is repeated for
these steps: every step that submits to a real queue counts as a print
the owner approves at the time, and the 1.2.1 values a step compares
with are captured before the candidate is installed. docs/TODO.md points
at the list and has an item for W70.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

style(tests): three blank lines after the helper tests' queue identifier e2b53d505f

The member added to PrinterWorkerHostTests by the one-queue change was
followed by one blank line where the convention is three (review of
that change, nit 7). The job it was run into gets the documentation
comment a member standing alone needs.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(runtime): the inventory failure line claims only what holds whatever failed 3c742531c5

On a connection that had delivered its inventory, the error for an
inventory that cannot be read said "This does not stop jobs: they are
claimed and printed as before". That is true only when the cause is one
queue's settings (confirmation review of the one-queue fix round, its
should-fix).

When the service's own stored data cannot be read, a lane needs the same
record before it claims: a job offered meanwhile is not claimed, and the
log also has "Print lane stopped" with the journal's reason. When the
spooler cannot list its queues, or the enumeration stalls, the list the
lanes make fails too, because the full discovery and the list begin with
the same enumeration (by reading; not run against Windows).

The line now says what always holds: "The inventory this connection
already delivered stays in force, so this failure by itself holds no
job; whether jobs go on depends on the reason." The other variant, for a
connection that has delivered none, is unchanged: nothing is claimed
until the inventory can be read. The causes it names now include a
spooler that cannot list its printers. Behaviour is unchanged.

The store-failure test now offers a job while the journal's table of
shared printers is out of reach. It must not be claimed, the lane's
failure must be logged with the journal's reason, and the job must be
spooled once the table is back. The test is renamed for what it shows.

docs/TROUBLESHOOTING.md says what to expect by cause: with one
printer's settings the other printers keep printing; with the spooler
or the stored data expect "Print lane stopped" and no printing until it
is repaired. The changelog, docs/REALTIME.md and ADR-0004 no longer say
that jobs go on whatever the cause.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(audit): a row for the helper answer without formats; W65 follows the corrected line bc9d45d373

W73 (confirmation review of the one-queue fix round, nit 1): a helper
answer to the lookup whose entry names the queue and has no formats is
not refused in words of its own. The job ends FAILED before SUBMITTING
with the platform's text for a missing value as its reason. Only an
answer that is not the shipped helper's can look like this, and two
tests pin it. Open. 126 rows become 127; nothing is renumbered.

W65's status said that jobs go on being claimed on the delivered
inventory. It now says when: with one queue's settings as the cause. A
cause the lanes share stops them too.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(adr): which broken queue shows the fix, and when the queue must break b1bfc3ae9f

Two additions to the hardware plan for the one-queue change
(confirmation review of the fix round, nit 2).

A connection to a dead print server holds the listing as well as the
full discovery, so it shows the known limit and not the fix. The fix is
shown only by a queue that holds the full discovery and does not hold
the list without media. The plan says which candidates of step 3 are of
which kind: the connection is of the first; the port that drops packets
and the damaged driver are meant to be of the second, which timing the
list settles.

For steps 7 to 9 the queue must break after the service has delivered
its inventory, or the run shows only the restart limit. Step 8 is
reordered: the FAILED job is observed first, the restart comes after.

Still a proposal: not agreed by the owner, not run.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(runtime): wait for the inventory that carries the printer's name, not for two inventories 3a7c2e7afc

JobsKeepPrintingOnTheDeliveredInventoryWhileTheFullDiscoveryFails names
a printer over the pipe straight after connecting and then waited for
two inventories: the connection's first, and a second that carries the
name. That holds only when the first inventory is read before the name
is saved. When the name is saved first, the first inventory already
carries it, nothing changes afterwards, no second inventory is sent and
the wait runs out after 30 seconds.

The test failed once in a full run of the Windows-layer suite for the
confirmation reviewer, and once in nine such runs here (the class alone
passed twenty times in a row). The run that failed here was made without
a result file, so its message was not kept; it failed 40 seconds into
the run, which fits a wait that ran out. The interleaving was then made
to happen in a scratch copy, by having every status round wait 1.5
seconds before it reads: the test fails there at that wait, with one
inventory received.

The test now waits until the server has received an inventory in which
the printer carries the name, whichever inventory that is. With the same
delay in the scratch copy the corrected test passes. No sleep is added
and nothing in the product changes.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

james.maes merged commit db45420b14 into release/2.0

2026-11-11 05:43:27 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qqq-print-agent#50