Skip to content

v3.3.3

Choose a tag to compare

@GkhanKINAY GkhanKINAY released this 09 Aug 11:25
· 82 commits to main since this release
e4a5edb

A self-audit of v3.3.2, on the principle that the round which fixes ten things is the round most likely to break an eleventh. Three did not survive the re-read.

The one that mattered

A founding purchase could have taken channels away. v3.3.2 added a channel sync to the redeemed-code path so that someone whose subscription lapsed and who then bought a lifetime deal would get their channels back. That sync runs in both directions. A founding purchase always grants Pro, thirty channels, and an organization still in its trial reads as Agency, a million — so a customer converting with more than thirty live channels would have had the excess switched off, at the moment they paid, on a path where nothing happened at all before. The give-back half is now its own function and that path calls only it.

Two smaller ones

A refused multipart upload was post-processed anyway: the media controller reads the upload location off whatever the handler returns, and several branches inside answer the request themselves — an unsupported extension, a body that does not match its declared type, and, new in v3.3.2, a key the organization never created. That threw on top of an already-sent response. The client always got the right status; the server logged noise it did not need to.

Reconnecting a channel left behind the marker that says the system switched it off, so a live channel could carry a claim that was no longer true. Nothing acts on it today, but a half-true invariant is how the next change goes wrong.

What was checked and left alone

Recorded in docs/ui-migration-log.md so the next pass does not re-derive it: the third-party function allowlist resolves the real provider's methods and refuses the inherited ones; the request organization does carry its subscription, and cancellation hard-deletes it, so the new autopost tier check reads Free after a cancellation as intended; the orchestrator never calls the method whose signature changed; and the upload-ownership map works on installs without Redis, because each app runs as a single process.

The previous round's guarantees were re-tested rather than trusted — a downgrade still switches off the newest channels first, an upgrade still respects a channel the user disabled themselves, and an owned upload key still gets through.

Upgrading

Nothing to do. No schema change and no workflow change in this release.

Full diff: v3.3.2...v3.3.3