Skip to content

docs: "Back Pressure" notes and various Javadoc - #508

Closed
Antony Stubbs (astubbs) wants to merge 484 commits into
masterfrom
docs/back-pressure
Closed

Antony Stubbs (astubbs) wants to merge 484 commits into
masterfrom
docs/back-pressure

Conversation

@astubbs

Copy link
Copy Markdown
Contributor

No description provided.

Partitions now track their highest succeed offset, for use bye encoders.

Instead of encoding only up to the highest succeeded offset, it would
attempt to encode the entire buffered partition state. This along with
a race condition in OffsetEncodingBackPressureTest#backPressureShouldPreventTooManyMessagesBeingQueuedForProcessing
was causing the test on CI to fail intermittently (and sometimes locally).

This change also makes the test behave consistently regardless of environment
performance.
Only allowing retries is naive as there may be records which are already
represented in the payload encoding which, if completed, may reduce it's size.

The encoders must encode all state up to the high succeeded offset, as any beyond that are
by definition incomplete and can be ignored. Any record who's offset is below this, will
be contributing to the size of the payload. Allowing them to attempt to be completed may
reduce the payload size.
Due to high load in parallel test execution mode, some operations are
taking slightly longer on slower machines, causing tests to fail intermittently.

To stabilize test execution - following tweaks were made:
- increased maxConcurrency in TransactionAndCommitModeTest
- increased pollTimeout in OffsetCommittingSanityTest
- increased delay in WorkManagerTest#testOrderedAndDelayed
- increased await timeout in OffsetEncodingBackPressureTest
…periodic-consumer-sync commit-mode

Timeouts on commits will cause the control-loop to exit.
Addresses issues reported:

- ConcurrentModificationException in ShardManager during Rebalancing #188
- NullPointerException in PartitionMonitor during Rebalancing #189

Notes:

- Improve impact of no-op removed state, so it won't be retrieved for analysis
- Change from removing revoked PartitionState instances to replacing with a PartitionRemovedState subclass
-- Advantage of this is there will never be NPE from stale references of work still in flight
-- Also means we can track history of assignment
- Several refactorings that have been waiting to happen related to the change
- Improved cohesion

Relates / Future improvements on this:

Refactor: Consider a shared nothing architecture, to reduce thread complexity #200
Cleans up warnings in logs of ignored properties.
Antony Stubbs (astubbs) and others added 18 commits January 13, 2023 13:41
…e out of order processing (#534)

Under unrealistically high load with no-op processing, broker poller unblocking a partition could cause ProcessingShard to skip forward in its entries and take work out of order.

This was discovered when fixing a synthetic high performance benchmark, after PR#530 (O(n) algo was fixed to O(1)), creating the state for the race condition to appear. Probably could not happen without the fix, as it's related to the performance of certain parts of the system.
…ork is stale (#549)

Co-authored-by: Ravi Kalasapur <rkalasapur@onetrust.com>
…itions are revoked (#548)

* Fix deadlock on partitions revoked

* Add unit test for rebalance deadlock on EoS

* Update changelog and readme

* merge with master changes

* Fix misplaced comment
Bumps `mockito.version` from 4.9.0 to 5.1.1.

Updates `mockito-core` from 4.9.0 to 5.1.1
- [Release notes](https://github.com/mockito/mockito/releases)
- [Commits](mockito/mockito@v4.9.0...v5.1.1)

Updates `mockito-junit-jupiter` from 4.9.0 to 5.1.1
- [Release notes](https://github.com/mockito/mockito/releases)
- [Commits](mockito/mockito@v4.9.0...v5.1.1)

---
updated-dependencies:
- dependency-name: org.mockito:mockito-core
  dependency-type: direct:development
  update-type: version-update:semver-major
- dependency-name: org.mockito:mockito-junit-jupiter
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: John Byrne <33546417+johnbyrnejb@users.noreply.github.com>
Bumps `vertx.version` from 4.3.6 to 4.4.1.

Updates `vertx-web-client` from 4.3.6 to 4.4.1

Updates `vertx-junit5` from 4.3.6 to 4.4.1

---
updated-dependencies:
- dependency-name: io.vertx:vertx-web-client
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: io.vertx:vertx-junit5
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [versions-maven-plugin](https://github.com/mojohaus/versions) from 2.14.1 to 2.15.0.
- [Release notes](https://github.com/mojohaus/versions/releases)
- [Changelog](https://github.com/mojohaus/versions/blob/master/ReleaseNotes.md)
- [Commits](mojohaus/versions@2.14.1...2.15.0)

---
updated-dependencies:
- dependency-name: org.codehaus.mojo:versions-maven-plugin
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [threeten-extra](https://github.com/ThreeTen/threeten-extra) from 1.7.1 to 1.7.2.
- [Release notes](https://github.com/ThreeTen/threeten-extra/releases)
- [Commits](ThreeTen/threeten-extra@v1.7.1...v1.7.2)

---
updated-dependencies:
- dependency-name: org.threeten:threeten-extra
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Avoid expensive calculation of properties for debug / trace logging when debug / trace logging is not enabled.

---------

Co-authored-by: Lenne Hendrickx <lenne.h@sparkcentral.com>
Bumps [maven-release-plugin](https://github.com/apache/maven-release) from 3.0.0-M7 to 3.0.1.
- [Release notes](https://github.com/apache/maven-release/releases)
- [Commits](apache/maven-release@maven-release-3.0.0-M7...maven-release-3.0.1)

---
updated-dependencies:
- dependency-name: org.apache.maven.plugins:maven-release-plugin
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…nkins (#583)

* update dependencies

* add maven wrapper

* Update jenkinsfile to use mvnw

* Add to changelog
* add instance id into thread name

* Add instance id to thread name if possible

---------

Co-authored-by: lixy <lixy@tuya.com>
Co-authored-by: Edward Vaisman <10497078+eddyv@users.noreply.github.com>
log.debug("Interrupting {} thread in case it's waiting for work", blockableControlThread.getName());
blockableControlThread.interrupt();
} else {
log.trace("Work box not being polled currently, so thread not blocked, will come around to the bail box in the next looop.");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
log.trace("Work box not being polled currently, so thread not blocked, will come around to the bail box in the next looop.");
log.trace("Work box not being polled currently, so thread not blocked, will come around to the bail box in the next loop.");

Comment on lines +87 to +101
// not used
// /**
// * The number of entries in the shard.
// * <p>
// * Used to filter by only entries available to be processed - but that doesn't make sense, as in KEY and PARTITION
// * ordering, only the head of the shard could be unavailable, so we iterate over the whole shard for nothing. In
// * UNORDERED mode, the whole shard may be unavailable, but as ths is only used to check if the poller should
// * throttle, we can't just continue buffering more records, as we'll run out of memory - should wait until the
// * currently buffered limits are processed.
// *
// * @return the number of entries in the shard
// */
// public long getCountOfWorkAwaitingSelection() {
// return entries.size();
// }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove?

Suggested change
// not used
// /**
// * The number of entries in the shard.
// * <p>
// * Used to filter by only entries available to be processed - but that doesn't make sense, as in KEY and PARTITION
// * ordering, only the head of the shard could be unavailable, so we iterate over the whole shard for nothing. In
// * UNORDERED mode, the whole shard may be unavailable, but as ths is only used to check if the poller should
// * throttle, we can't just continue buffering more records, as we'll run out of memory - should wait until the
// * currently buffered limits are processed.
// *
// * @return the number of entries in the shard
// */
// public long getCountOfWorkAwaitingSelection() {
// return entries.size();
// }

@eddyv Edward Vaisman (eddyv) added documentation Improvements or additions to documentation wait for info Waiting for additional info from user labels Jun 20, 2023
@cla-assistant

cla-assistant Bot commented Aug 8, 2023 •

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ eddyv
❌ astubbs
You have signed the CLA already but the status is still pending? Let us recheck it.

Antony Stubbs (astubbs) added a commit to astubbs/parallel-consumer that referenced this pull request Aug 12, 2026
…he sweep tool a mode that could have caught it (#258)

* docs(upstream-map): track the 28 issues closed by the 2023 admin sweep

Upstream ran two bulk clearouts before going quiet, and neither was a triage:
2023-06-15 `eddyv` closed 35 unmerged PRs with "Closing - Stale." (34 of them
ours), and 2023-07-07 `johnbyrnejb` closed 28 issues with "Closing Issue" -
every one marked COMPLETED rather than "not planned".

That state reason is why the cohort was invisible. GitHub renders `completed`
as resolved, so the issues read as done at a glance, and `upstream-sweep.sh`
searches `updated:>=last_swept`, so anything last touched in 2023 can never
appear in a sweep. None of the 28 were in this manifest; the mirroring that
produced the other 78 fork mirrors only ever sampled *open* upstream issues.

All 28 were re-read in full - bodies plus all 58 comments - and each verified
against fork source rather than trusted from its thread. That mattered: four
issue bodies point at PRs that "fix" them (#372->#390, #319->#270, #203->#345,
#191->#346) and every one of those PRs was itself swept unmerged.

Result: 2 already fixed (#41 offset-scan removal, #319 shutdown CME), 6 partly
addressed, 20 fully open. Grouped into work items rather than 28 near-duplicate
entries, since several want designing together - per-topic handlers with
separate consume/produce types, seek with subscription changes, retry expiry
with stall detection. #57 folded into the existing log-noise entry.

Swept PR head commits were checked and are all still reachable, so the drafts
are recoverable; entries cite branch and SHA, not just the PR number.

Upstream-Issue: confluentinc#154
Forwarded: no
Applied-Upstream: no

* docs(upstream-map): mirror the whole 2023 cohort, not the parts we rate

The point of mirroring is a clean, known cutoff - "every issue upstream closed
administratively is accounted for here" - not a curated pick of the good ones.
A set filtered by our own value judgement is not a cutoff: the next person
cannot tell "not mirrored because it was junk" from "not mirrored because it
was missed", and that ambiguity is worth far more than the cost of carrying a
few items nobody will ever action.

Drops the decline recommendations from #53, #199, #246 and #57 in favour of
neutral statements of the trade-off, and renames sweep-2023-decline-candidates
to sweep-2023-small-items (status wontfix -> none). The facts that informed
those recommendations are kept - they are useful to whoever picks the issue up
- but they are now framed as input to that person's decision rather than as our
verdict delivered in advance. Fork issues can always be closed later on their
merits, which leaves a visible record; pruning before mirroring does not.

Records the principle in the section header so a later pass does not re-prune.

Upstream-Issue: confluentinc#154
Forwarded: no
Applied-Upstream: no

* docs(upstream-map): link the created fork mirrors back to their entries

The 28 mirrors are live as #227-254 (label `upstream-admin-closed`),
with confluentinc#41 -> #233 and confluentinc#319 -> #252 created
and immediately closed as completed, carrying the code evidence that they are
genuinely fixed.

Records the fork numbers on each entry so the mapping is queryable rather than
re-derived, which is the reason this file exists. Adds `fork.fork_issues` (the
plural of the existing `fork_issue`) because several entries deliberately group
upstream items that want designing together, and documents it in the schema
block. Verified: all 28 mirrors are referenced, none missing, no strays.

Also snapshots each upstream title verbatim into its mirror body header, dated
2026-08-07 - the fork titles may drift as these are worked, and the original
wording is what makes an old thread findable.

Upstream-Issue: confluentinc#154
Forwarded: no
Applied-Upstream: no

* fix(tooling): give upstream-sweep a mode that can see closures it never saw

The default sweep is a window search - `updated:>=$since` - so it structurally
cannot see an item whose last activity predates the window, and `last_swept`
only moves forward, so the blind spot grows. That is why upstream's 2023
administrative closures went unnoticed for three years: 28 issues closed with
"Closing Issue" and 35 unmerged PRs closed as "Closing - Stale.", all marked
COMPLETED, none of it triage, none of it visible to us.

Adds `--audit`: no time window, asks "which closed upstream items are neither
tracked in the manifest nor mirrored in the fork?", and flags days where an
implausible number of things closed at once. Run against the real repo it
rediscovers both sweeps from scratch and reports zero unaccounted, which is
also an end-to-end check that the new fork_issues linkage is correct.

Bots are excluded from the PR analysis. Dependabot self-closes superseded
bumps in batches that look exactly like a sweep - 2022-08-16, 2022-10-20,
2023-11-03 and 2024-01-25 are all dependabot - and unfiltered they buried the
two real sweeps in noise. Filtering them surfaced two human PRs that had been
sitting inside those batches (confluentinc#508, confluentinc#650), now recorded
for review.

The report says outright that a bulk day is not proof of a sweep, because a
release triage looks identical from here, and that stateReason COMPLETED is not
evidence of a fix - that assumption is what made this cohort invisible.

Known remaining hole, recorded not fixed: a PR closed alone on a quiet day is
still invisible, since detection keys on bulk.

Upstream-Issue: confluentinc#154
Forwarded: no
Applied-Upstream: no

* fix(tooling): teach the audit about Discussions, a content type we never checked

Discussions were invisible to everything: not in the manifest, not mirrored,
not in any sweep mode. 74 of them upstream, and nothing we run would ever have
mentioned one.

They were NOT swept - no bulk closure, and the largest day (2024-04-02, six
threads) is all answered=true housekeeping. So the failure mode is different
from the 2023 cohort: not administrative closure, just questions nobody
answered, in a place no issue search reaches. Handling differs accordingly -
these want answering or converting, not mirroring wholesale.

The audit now lists zero-reply discussions, excluding release-announcement
threads by title: those legitimately have no replies, and counting them as
neglect would put 9 false positives at the top of the report.

Two finds justify the check on their own. Discussion 542 (zero replies) is a
field report of a transactional consumer stuck in rebalance because it cannot
acquire the produce lock, with the reporter suspecting the revoke-time flush -
the same lock lifecycle as bug-producing-lock-double-release, and they raised
the timeout without effect, which is evidence about the mechanism rather than
the duration. Discussion 883 (zero replies) is the same complaint as fork
mirror #187 but with a runnable reproducer, which #187 lacks.

Upstream-Issue: confluentinc#154
Forwarded: no
Applied-Upstream: no

* docs(inflight): record the open obligation to account for every upstream item

Two notes, both about what is NOT done.

Discussions are not a queue to be converted. There is no pipeline turning
threads into issues, and most should never become one. The rule is a judgement:
if reading a discussion makes us think there is an issue, we raise one - a
normal fork issue on its own merits, citing the discussion as where it came
from. It exists because we believe the problem is real, not because a thread
existed. That also keeps `upstream-mirror` meaning exactly "an upstream issue
we carry", which is what makes the 2023 cutoff verifiable.

The wider obligation is now written down: every upstream issue, PR and
discussion must be accounted for - carried, declined, or genuinely resolved
upstream - not sampled. The 2023 cohort was found only because it was a *bulk*
event; `--audit` keys on bulk closures and zero-reply threads, and both are
proxies that miss whole shapes of problem (a PR closed alone on a quiet day, a
discussion with one dismissive reply, an issue marked COMPLETED with no linked
PR). The audit narrows the field; only reading discharges the obligation.

Also records what has been ruled out, so it is not re-investigated: wiki
disabled, no advisories, all open-milestone issues already mirrored, the orphan
branches accounted for (v0.6.x-dev is the lambda-actor work already captured
via swept PRs; 0.5.3.x's regression fix IS on master as a908e16), and
"upstream pushed today" being a pushed_at artefact rather than new activity.
Left open: project boards need a read:project scope we do not have, and 169
forks are unexamined.

* fix(upstream-map): use a group the schema actually allows

Two new entries used `group: batching-ordering`, which is not in the GROUPS
allow-list in scripts/upstream-map.py, so `upstream-map.py validate` failed on
them. Caught in review on #258.

My mistake was validating the wrong way: I checked the file with an ad-hoc
yaml.safe_load plus a duplicate-id check, which passes happily on a group the
schema rejects, instead of running the project's own validator that AGENTS.md
tells contributors to run before committing manifest changes.

Reassigned both to `features` rather than widening GROUPS. The rest of this
cohort's feature entries already use `features`, so this keeps the cohort
internally consistent, and the ordering/batching distinction is not lost - it
lives where it belongs, on the issues themselves via the `area/batching-ordering`
label (#244, #236). Adding a vocabulary term to a shared schema as
a side effect of a mirroring PR is the larger, less reversible change.

Also drops the redundant 345 from sweep-2023-broker-disconnect-commit's
`related` list, where it already appears in `prs`.

Verified: `upstream-map.py validate` reports OK on 27 entries, and `refs` and
`table` both still render.

* docs(upstream): graduate the durable parts of the sweep record out of inflight

The three inflight notes stay - they hold undischarged work - but they were
also carrying permanent content, and inflight is transient by its own charter.

Moved to durable homes, each citing the manifest rather than restating it:

- docs/upstream.md gains the upstream-admin-closed cohort note (with the
  "do not trust 2023-era closure states" rule), the discussions non-mirroring
  policy decided 2026-08-07, documentation of --audit and its known blind
  spots, and the ruled-out upstream surfaces (wiki, advisories, milestones,
  orphan branches, pushed_at).
- docs/solutions/ gains the transferable lesson: a closure state is a
  rendering choice not a triage, "fixed by #N" must be checked against the
  merge bit, windowed watchers need a no-window audit, and bots must be
  filtered before hunting bulk events.
- upstream-pr-analysis.adoc is corrected: it claimed issues were never
  bulk-closed, which the 2023-07-07 sweep disproves, and the PR sweep is
  now confirmed rather than suspected.

The inflight notes now hold only open work, pointing at the new homes.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs(upstream): name the analysis doc's role (the plan) beside the manifest (the state)

docs/upstream.md's opening enumerated everything it owns except the
editorial analysis, and neither source-of-truth reference was a clickable
link. Now the two roles are named explicitly: the .adoc is the plan, the
manifest is the state tracker.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(upstream): make the audit's discussion query actually paginate, and correct the sweep cohort

Address PR review feedback (#258).

- upstream-sweep.sh: `gh --paginate` only substitutes a variable named
  `endCursor`; calling it `$cursor` meant the cursor was never fed back and gh
  re-requested page 1 forever (reproduced: 469 identical pages at first:2).
  It only looked healthy because 74 discussions fit in one page of 100. The
  failure was also swallowed by `2>/dev/null || true`, which would have printed
  a clean "(none)" for a broken query - the one answer this mode must never
  invent. Fail loudly instead.

- upstream-map.yaml: the sweep cohort listed 36 PRs against a documented count
  of 35. Upstream closed exactly 35 unmerged PRs on 2023-06-15; confluentinc#66
  (closed 2022-10-19) was carried in by mistake. Listing a ref here marks it
  accounted for, so it was hiding an unrelated PR from every future audit.
  Recorded PR 258 and moved the entry to `pr-open` per the lifecycle rule.

- next-upstream-coverage-completeness.md: dropped the cached counts - inflight
  notes must not record what a command can answer, and the "~100 partially
  mirrored" line already contradicted docs/upstream.md, which says all 78 open
  upstream issues are mirrored with backlinks. Kept only what the audit cannot
  say: what nobody has read yet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(agents): let the manifest cache frozen upstream-issue facts, and say why

The rule said "the manifest tracks upstream PRs only", so mirroring the 2023
sweep cohort into it read as a violation. The rule is what is out of date.

An archived upstream's closed issue numbers and closure events are frozen. Caching
them locally is a read-path optimisation, not a second tracker: grepping one file is
instant, while the same answer from the mirrors costs dozens of API round-trips and
burns rate limit shared across agents. The usual objection to duplication - the copy
silently diverges - needs a source that can still move, and this one cannot.

So the boundary is redrawn where it actually bites: the mirror owns an issue's *live
state* and remains the only place you update it; the manifest may cache what is frozen
(number, cohort, owning mirror). Cache what is frozen; never mirror what is moving.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(upstream): put the manifest-caching rule in the doc that owns it

The previous commit wrote the rule into AGENTS.md, which is the one place it
does not belong. AGENTS.md's own preamble calls itself a router - "if it only
matters once you are already in a topic... it goes in that topic's doc" - and
docs/upstream.md line 7 already claims ownership explicitly: "AGENTS.md carries
only the pointer and the one-line rule that manifest upkeep is the agent's job."

The rule was in fact already stated twice before this branch (AGENTS.md:442 and
docs/upstream.md:23), so growing the AGENTS.md copy deepened a fragmentation that
was already there. Now stated once, where an agent editing the manifest will
actually be looking, with AGENTS.md left holding the pointer and the one binding
rule whose failure is silent (keep the fork side in sync).

Net effect on the router: one line shorter than master, despite covering more.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(agents): make a pointer say who owns the rule, not just what is nearby

Diagnosed from a live miss. A reviewer cited AGENTS.md's "the manifest tracks
upstream PRs only", so that section was read and treated as authoritative - while
docs/upstream.md had been stating the same rule, and claiming ownership of it, the
whole time. The duplicate was then grown in the router rather than fixed at source.

Nothing in the reading path revealed the mistake. AGENTS.md stated a complete-looking
rule and followed it with a pointer listing four adjacent mechanics ("the manifest
schema, the mirrors, the commit trailers and the upstream sweep"), which reads as
*further detail*, not as *this is a summary and that doc wins*. The contract was
written down - docs/upstream.md:7 - but only on the side nobody enters from, since
AGENTS.md is what loads every session.

The anti-duplication rule already existed here ("Never state a fact twice"). What was
missing is the half that makes it discoverable: a cross-reference must name the owner
and say the owner wins, so a reader can tell a stub from the whole rule before editing
the copy. Applied to the rule itself and to the upstream pointer that failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Antony Stubbs (astubbs) added a commit to astubbs/parallel-consumer that referenced this pull request Aug 17, 2026
…archive tags, and correct the audit note's branch-only containment check

Extends the 2026-08-14 preserved_heads pass (swept PR heads) to ALL upstream
branch tips. Every non-bot upstream/* tip is now reachable from an origin
branch or pinned as an annotated archive tag on origin:

- Ten tips were reachable from nothing on this fork; now tagged
  archive/upstream-branch/<name>: 0.5.3.x, v0.5.2.x-dev, v0.6.x, master
  (upstream's final tip), docs/back-pressure (swept confluentinc#508 head,
  out of the 2026-08-14 pass's scope), features/batching,
  PL-176/DontDrainIssue, python-cd-pipeline, correct-failing-license-check,
  DP-12547. Tag/SHA record: preserved_branch_tips in upstream-map.yaml, same
  single-source contract as preserved_heads; method in docs/upstream.md.
- 18 dependabot/renovate/chore branches deliberately NOT preserved -
  recreatable version bumps, not work.
- Corrects the previous commit's inflight note: its containment check used
  `git branch -r --contains`, which cannot see tags, so it wrongly reported
  four already-tag-preserved heads (rebalance-messages, remove-static,
  dynamic-concurrency-control, vertx-vertical) as lost, and missed that
  features/retry-exception's upstream tip is contained in another origin
  branch. The trap is now recorded in docs/upstream.md next to the command.

Verified: all 10 tags on origin (git ls-remote --tags origin
'archive/upstream-branch/*' returns 10); scripts/upstream-map.py validate
green; issue-ref gate green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqHpNSXC39ANv9kG1ZvUzn
Antony Stubbs (astubbs) added a commit to astubbs/parallel-consumer that referenced this pull request Aug 18, 2026
…es, back-fill five entries, preserve ten upstream branch tips (#305)

A full audit of all origin branches against the tracking corpus found the
manifest blind to whole families of 2022 draft work, and several upstream
branch tips preserved nowhere on this fork.

Registration and back-fill:

- New entry sweep-2023-actor-ipc: the micro-actor framework branch family
  (lambda-actor-bus, commit-command-actor, poller-bus-actor, actor-scheduled,
  transactions-dont-block, scheduled-commit, remove-commit-queue). Until now
  confluentinc#325/confluentinc#524 appeared only inside the admin-sweep bulk
  PR list, so no audit could see the family.
- New entry refactor-thread-model-god-class: registers the confluentinc#200 /
  confluentinc#488 branch graveyard (fork mirror #142).
  refactor/controller-extract-base was in no tracking doc at all.
  docs/refactoring.md stays the editorial owner; both sections cross-reference
  their manifest ids.
- Back-filled fork.branches on five entries that recorded the upstream item
  but not the fork branch carrying its draft: sweep-2023-async-produce (also
  fixing its wrong branch name and stale SHA), sweep-2023-tx-failure-taxonomy,
  sweep-2023-retry-lifecycle, sweep-2023-topic-priority, sweep-2023-long-tail.
- poller-bus-actor added to docs/refactoring.md's Actor/IPC section: it
  carries the second, unreconciled actor base.

Preservation, extending the preserved_heads pass from swept PR heads to ALL
upstream branch tips:

- Ten non-bot tips were reachable from nothing on this fork; now pinned as
  annotated archive/upstream-branch/<name> tags on origin: the release lines
  (0.5.3.x, v0.5.2.x-dev, v0.6.x), upstream's final master, docs/back-pressure
  (the swept confluentinc#508 head), features/batching, PL-176/DontDrainIssue,
  python-cd-pipeline, correct-failing-license-check, DP-12547. Tag/SHA record:
  preserved_branch_tips in upstream-map.yaml, same single-source contract as
  preserved_heads; method in docs/upstream.md.
- The dependabot/renovate/chore branches were deliberately not preserved:
  recreatable version bumps, not work.
- Records the containment-check trap alongside the method: git branch -r
  --contains cannot see tags, so re-running the 2026-08-14 command verbatim
  reports already-tag-preserved heads as lost.

docs/inflight/next-branch-audit-orphans.md carries what remains open: the
orphan branches still needing attribution, the unassessed preserved tips
(PL-176/DontDrainIssue, features/batching), and the sweep-tool branch-audit
mode that would keep untracked work from regrowing.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation wait for info Waiting for additional info from user

Projects

None yet

Development

Successfully merging this pull request may close these issues.