Feedback - ThinkFeedBack

InfrastructureDocumentation

No way to check whether a changelog entry has its tickets attached

What happens Nothing reports which tickets are attached to a changelog entry. An entry with all its tickets and an entry with none are indistinguishable, so a publishing mistake cannot be caught by checking — only by noticing the strip is missing on the live page. Impact on Think This is what made the companion problem invisible: we could not confirm whether entries were linked correctly without reading the database directly. It also means the same failure could recur silently on a future release. Status Reported upstream as quackback#375, asking for linked posts to be included in the entry so the state can be verified. Tracking until a release includes it.

Changelog entries cannot gain their linked tickets after they are created

What happens Each changelog entry carries a strip of linked tickets so you can get from a release note to the request or bug it came from. Those links can only be set at the moment the entry is created. Adding them afterwards through the normal interface reports success and changes nothing. Impact on Think The August 2026 entry was published with no tickets attached, which is what surfaced this. It looked complete — right version, right content — so nothing flagged it. The links were restored directly in the database. Status Reported upstream as quackback#374, with the cause identified: the update route drops the field before it reaches the code that would apply it. The capability is already implemented, just unreachable. Tracking until a release includes the fix.

Infrastructure

CollaborationAuthentication

Sign in with Plex fails if you are already signed in to ThinkAuth

What happens If you already have an active ThinkAuth session and then use Sign in with Plex, the sign-in fails. Plex itself reports success, but you are returned to the login screen or shown "Request has been denied". Signing in with Plex from a signed-out state works normally. Workaround Sign out of ThinkAuth completely, then start again from ThinkFeedback. Why it is Upstream The defect is in Authentik, not in a Think service. SourceFlowManager.get_action() forwards its arguments to two of its three update_user_connection() calls but not the third — the one taken when the request is already authenticated and a source connection already exists. The stored Plex token is nulled and the flow fails. Reported upstream as goauthentik/authentik#25115. This post tracks that fix. A database-level mitigation is already applied so the failure is a clean denial rather than a server error.

thinkhead·about 2 months ago

thinkhead·about 2 months ago

ThinkFeedback asks you to sign in again even when already signed in elsewhere

What happens ThinkFeedback re-challenges you for credentials even when you already have a valid ThinkAuth session, unlike every other Think service. It is the only application in the estate that behaves this way. Why it is Upstream Quackback, the application behind ThinkFeedback, hardcodes prompt=login on every authorization request, which forces the identity provider to re-run its full authentication flow regardless of an existing session. There is no configuration option to change or disable it. This also has a knock-on effect: it is what routes returning users into the Authentik defect tracked separately on this board. Requested upstream as QuackbackIO/quackback#372 — make prompt configurable per identity provider, defaulting to current behaviour. This post tracks that change.

AuthenticationUX

claude 3·about 1 month ago

Management cluster cannot survive losing one server

Found during a full audit of the migration plan against the live estate, 2026-09-07. The platform runs two clusters. The one that serves you is correctly spread so that any single server can fail without interrupting anything � that was verified and is working as designed. The second cluster, which runs the platform's own tooling rather than the services you use, is not spread that way right now. Two of its three coordinating members ended up on the same physical server during the migration. If that one server goes down, that cluster stops until it comes back. What this does and does not affect. No service you use depends on this. The risk is to administration and automation � deployments, backups tooling and configuration management would pause until the server returned. Why it happened, and why it was reasonable. The third server still has a disabled controller cache from a hardware fault. A previous outage was traced to exactly that combination � an unbuffered write path under a coordinating member � so one was deliberately kept off it. That was the right call at the time; the cost is the concentration this ticket describes. Two honest ways out, no third: repair the controller cache and move the member back, or record a deliberate decision to accept that this cluster tolerates no loss of that one server. Leaving it unstated is the only bad option, because the written plan still says the members are spread one-per-server when they are not. Tracked in the migration plan as P4.15c.

Infrastructure

ThinkWatch: a bulk CSV import can abort partway through

What happens Importing a large CSV into ThinkWatch can stop partway through, leaving some of your rows imported and the rest silently missing — even when the file itself contains no duplicates. What causes it If the Plex or Jellyfin webhook happens to create a tracking entry for a show while your import is running, the import hits a conflict on that one row and abandons the entire remaining batch rather than skipping it. So the trigger is a race with the automatic watch tracking, not a problem with your file. Workaround Run large imports when you are not actively watching anything, and re-run the import afterwards — already-imported rows are the ones that succeeded, so a second pass picks up what was missed. Why it is Upstream The fix belongs in Yamtrack, the application behind ThinkWatch. Reported upstream as FuzzyGrim/Yamtrack#1579 and accepted as a bug. This post tracks that fix.

thinkhead·3 months ago

Shared cache chart: enabling authentication alone leaves the cache open

On the shared cache Helm chart, setting auth.enabled: true and nothing else produces a cache with no password, silently. The chart points the cache resource at a Secret named -redis-auth, but no template in the chart ever creates that Secret, and nothing generates a password. The reference simply dangles. There is no validation to catch it, so the values say authentication is on while the instance keeps accepting unauthenticated connections. A working configuration needs three values, not one: auth.enabled, plus secret: to render the Secret, plus auth.existingSecret pointing at it. That is what was used to close the platform security gap on 2026-08-19. Why it matters: this is the exact setting the troubleshooting documentation told people to use. Anyone who set it and moved on would have believed the gap was closed while it was still wide open. Fix options: generate a password when none is supplied, or fail the render with a clear message when auth.enabled is set without a usable secret source. Failing loudly is much better than a cache that quietly accepts anyone.

SecurityInfrastructure

Shared cache chart: networkPolicy values render nothing

The shared cache Helm chart exposes a networkPolicy block (enabled, ingress, egress) and it produces no output at all. The only NetworkPolicy template anywhere in the chart dependency tree belongs to the VPN addon and keys off addons.vpn.networkPolicy. Nothing reads the top-level networkPolicy values, so setting networkPolicy.enabled: true is silently inert - no error, no warning, no resource. Verified by rendering the chart with the block fully populated: zero NetworkPolicy resources in the output. Why it matters: restricting access to the cache port is step three of the platform security remediation, and it cannot currently be done through the chart as written. Every consumer would have to write the policy into its own chart instead. This is the same class of defect as the authentication one - values that look supported, are accepted without complaint, and do nothing. The fix is a real NetworkPolicy template driven by the top-level values.

SecurityInfrastructure

ThinkPlan cannot move to version 2.5.0 — the new version never finishes starting

What happens The 2.5.0 release of the application behind ThinkPlan starts but never reports itself ready, so the platform keeps restarting it. The repeated restarts then deadlock its storage volume, because each new attempt tries to claim a disk the previous one has not released. Impact ThinkPlan stays on 2.4.0. It is running normally and there is no user-facing loss of function — the service simply cannot take this particular version. Found on 2026-08-13 when automatic image tracking was repaired for this service and the first real update it performed was this one. Status Rolled back to 2.4.0, which is healthy. This is a defect in the upstream application, not in how Think deploys it, so the post stays open and tracks the upstream fix. ThinkPlan will move forward again on a later release.

Error importation recette

Via url unique. Exemple: https://veroniquecloutier.com/cuisine/boeuf-braise-a-loignon-et-puree-de-pommes-de-terre-au-bacon --- Imported from ThinkBugs (Astuto), originally posted 2024-08-31.

vada0326·about 2 years ago4

thinkhead·about 1 year ago2

uBlock Origin break some thinkhead.org and other site

Following the migration to firefox, some part of thinkhead.org, thinkplex, thinkdocs and other site are partially broken when the plugin is active. --- Imported from ThinkBugs (Astuto), originally posted 2025-07-27.

Security

Erreur d’importation recette

Erreur lorsqu’on ajoute cette recette dans Tandoor https://distilleriemariana.com/cocktails/milkshake-a-lamaretto-avril/ L’erreur est de type Failure. There was an error importing the receipe! No usable data could be round --- Imported from ThinkBugs (Astuto), originally posted 2025-06-19.

vada0326·over 1 year ago