Merge 3.0.34 into 4.0

[antobinary]

Merging BBB 3.0.34 into v4.0.x-develop — report

Branch

antobinary/merge-3.0.34-into-4.0 → https://github.com/antobinary/bigbluebutton/pull/new/merge-3.0.34-into-4.0

12b399c8fb  fix(test): drop duplicate symbols the 3.0 merge appended to the playwright suite
406288d2e5  revert(plugins): drop the 3.0 use-timer data-consumption hook on 4.0
119e7baa03  fix(webcam): adapt 3.0 camera-dock grid snapping to the 4.0 layout set
16c50a0367  Merge tag 'v3.0.34' into v4.0.x-develop

Scope: 86 commits / 15 PRs since the 3.0.33 merge base, 92 files. 68 of those 92 files had also been changed on 4.0 — 74% genuine divergence.

The 21 conflicts

#	File	Resolution
1	bigbluebutton-release	4.0 (kept 4.0.0-beta.5-wip)
2	.gitlab-ci.yml	4.0 build image
3–4	akka-*/Dependencies.scala	4.0 — comment-only reword, versions auto-merged
5	bbb-recording-imex/pom.xml	stays deleted — module removed in 4.0; 3.0 side was a dependabot bump
6	bigbluebutton.properties	4.0 — html5PluginSdkVersion 0.1.24 (4.0 is on the 0.1.x SDK line, 3.0 on 0.0.x)
7	VoiceApp.scala	both — 3.0's orphaned-voice-join fencing + 4.0's userRole lookup, which the merged call still consumes
8	ApiController.groovy	both — 4.0's XML/URL validation gate on top of 3.0's async upload pipeline
9	external-video component	3.0 wholesale — 4.0 had no autoplay-mute recovery
10–11	html5 package.json + lock	regenerated
12–14	it_IT/ja/zh_TW	per-key three-way merge
15–16	playwright sharednotes .ts/.spec.ts	4.0 — superset; differences are 4.0 selector renames
17–20	4 docs files	mixed, see below
21	docs/package-lock.json	regenerated

Lockfiles. Taking either side wholesale was wrong in both directions: 4.0's lock silently dropped seven 3.0 security bumps, while 3.0's lock regressed 287 docs packages. I started from 4.0's and npm update'd only the affected transitive packages — fast-uri (html5) and body-parser, fast-uri, js-yaml, nanoid, postcss, shell-quote (docs). Both locks are now >= each side on every package, and neither package.json was modified.

Locales. The obvious rule ("changed on both sides → keep 4.0") was wrong: 22 keys per file were keys new in both, where 4.0 seeds the English source string and 3.0 carries the real translation. Using en.json as the reference, those 22 took the translation.

Docs. new-features.md is a curated 4.0 rewrite (335 lines vs 3.0's 589), and the 3.0 topics are already covered elsewhere in the 4.0 tree — so 4.0 for the structural hunks. But I ported the two 3.0.33 feature sections (BlockNote Markdown import/export, Panopto) that 4.0 documents nowhere, with the defaults corrected: 3.0 says "disabled by default", 4.0 ships both toggles true.

Re-implementations (separate commits)

CUSTOM_LAYOUT — 3.0's grid-snapping references LAYOUT_TYPE.CUSTOM_LAYOUT, which 4.0 deleted. Kept the intent: of the layouts 4.0 still has, UNIFIED_LAYOUT is the grid one.

use-timer plugin hook — merges textually but needs TimerData and DataConsumptionHooks.TIMER, which exist only on the 0.0.x SDK line. I checked the published SDK: neither 0.1.24 nor 0.1.25 (latest 0.1.x) declares TIMER. There is no version to bump to, and 0.0.104 would drag 4.0's plugin API back to 3.0. Removed the client half rather than leave 4.0 unbuildable — it needs a real SDK-side port.

Build from source — everything compiles

Component	Result
bbb-common-message (sbt)	PASS
bbb-common-web (sbt)	PASS
akka-bbb-apps (sbt compile)	PASS — validates VoiceApp.scala
bigbluebutton-web (gradle compileGroovy)	PASS — validates ApiController.groovy
html5 client (webpack)	PASS → deployed as b7b77b67fe9b485f5967
tsc --noEmit	clean

I installed sbt in the container and published the SNAPSHOT artifacts via publishM2 (gradle uses mavenLocal(); publishLocal writes to Ivy, which is why the first attempt failed). Pre-merge client backup kept at /root/html5-client.backup-merge3034.

Playwright: 315 passed / 29 failed / 17 skipped — 0 regressions

I ran the project's own CI gate (--grep @ci --grep-invert '@flaky|@need-update|...'), then built the exact pre-merge client (e1e3f4d8...) in a worktree, deployed it, and re-ran the failing areas to attribute every failure:

Fail on both merged and pre-merge	25 — pre-existing in this environment
Fail only after the merge	4 (chat) — flaky: all pass in isolation, and the full chat spec re-runs 27/27
Fail only pre-merge	1 — fixed by the merge: "No blank presentation area on slide change with a cold cache", i.e. 3.0's decode-gate work landing correctly

Two caveats on the numbers: an early run showed 23/24 shared-notes failures purely because bbb-shared-notes-server was inactive (started it → 24/24). And this container's .env secret is stale — the live one is YvuMwv...; I overrode it per-run rather than edit the file.

The thing that actually worries me

The conflict list was not the risk surface. All 21 conflicts were resolvable and none of them broke anything. What broke the build were two files git merged cleanly:

• sharednotes/blocknote/util.ts — 3.0's backport appended its own startSharedNotesBlockNote and getBlockNoteReadOnlyLocator to a file that already had both. The 3.0 copies call e.sharedNotes, which doesn't exist in 4.0's elements.ts at all.
• whiteboard.spec.ts — import { linkIssue } landed twice.

Duplicate top-level declarations are a hard SyntaxError for the Playwright loader: the entire suite collected 0 tests in 0 files. Not "the shared-notes tests failed" — every spec failed to import. Nothing in git's output hinted at it, because the additions were textually far apart.

This is the same failure mode as 5840bc2984 ("restore BlockNote shared-notes helpers dropped in 3.0->4.0 merge") from the previous 3.0 merge. It has now happened twice.

Merge vs. replay — recommendation

Keep merging, but change what happens after the merge.

The decisive argument is ancestry. A merge advances the merge base, so the next 3.0→4.0 merge only considers genuinely new commits. Replaying doesn't record that: git would re-present the same 86 commits forever, and the usual escape hatch (git cherry / patch-id) breaks precisely on the commits you had to adapt — the adaptation changes the patch-id, so the tool stops recognising them as applied. Given 74% file-level divergence, you'd be adapting a lot, so you'd be poisoning the detector on exactly the commits that matter. That cost compounds every release; the merge's cost does not.

Replay's real advantage is reviewability, and you can have that without giving up ancestry — which is what I did here: mechanical resolution in the merge commit, every judgement call in its own follow-up commit with the reasoning in the message. A reviewer can read three small commits instead of auditing a 57-file merge blob.

Replay only wins where a 3.0 PR shouldn't exist on 4.0 at all. The use-timer hook is the case in point: replay would simply skip it, whereas merging forced me to merge-then-revert. That's one PR out of fifteen — not enough to change the strategy, and the revert commit documents the decision better than a silent omission would.

So, two concrete process changes:

1. A post-merge gate, because the conflict list lies. Cheapest first: npx playwright test --list takes seconds and would have caught both fatal duplicates immediately. Then tsc --noEmit on the client and the playwright project (that's what caught CUSTOM_LAYOUT and the SDK mismatch), sbt compile + gradle compileGroovy, and a lockfile diff against both parents. None of these are in CI for merge commits today, as far as I can tell.

2. Fix the upstream cause of the duplicates. Both incidents come from the same pattern: a 4.0-originated test file backported to 3.0 with renamed selectors, then merged forward. Either keep backports symbol-identical to the 4.0 original, or put 3.0-specific adaptations in a 3.0-only file that has no forward-merge counterpart. Otherwise this recurs every release, and it's a silent, total test-suite outage each time.

One caveat worth flagging rather than burying: new-features.md is release-line-specific prose, and I made editorial calls a mechanical merge can't justify. That file deserves a docs-team pass before this merges.

[github-actions]

🚨 Automated tests failed

• Github workflow run