Skip to content

Ship staging to production - #1902

Open
postiz-contribution[bot] wants to merge 261 commits into
mainfrom
staging
Open

postiz-contribution[bot] wants to merge 261 commits into
mainfrom
staging

Conversation

@postiz-contribution

@postiz-contribution postiz-contribution Bot commented Aug 17, 2026 •

Copy link
Copy Markdown

In this batch

No merged PRs in this batch yet.

Before you merge

  • New environment variables (92): AGENT_API_KEY, AGENT_MEDIA_SSO_KEY, APPLE_APP_BUNDLE_ID, BACKEND_URL, CHATBASE_TOKEN, DATAFAST_API_KEY, DATAFAST_WEBSITE_ID, DISABLE_IMAGE_COMPRESSION, DISABLE_REGISTRATION, DISABLE_SSRF_PROTECTION, DISABLE_X_ANALYTICS, DISALLOW_PLUS and 80 more. Set them on production before merging.
  • Environment variables no longer referenced (3): APPLE_BUNDLE_ID, APPLE_SERVICE_ID, EMAIL_FROM_ADDRESS.
  • Dependencies (2): package.json, pnpm-lock.yaml
  • Infrastructure and deploy config (1): docker-compose.dev.yaml

giladresisi and others added 10 commits August 2, 2026 13:47
Threads moved its website from threads.net to threads.com, and
threads.net/oauth/authorize now 301-redirects to threads.com. For some
users that legacy-domain redirect drops the OAuth query parameters,
landing them on the Threads homepage instead of the consent screen.
Pointing the authorize URL directly at threads.com skips the redirect.
The graph.threads.net API endpoints are unaffected and remain supported.
…odal

addTag emitted the raw tag objects from the mutate result instead of the
{label, value} name mapping the save endpoint matches on, so whenever the
last tags interaction before saving was creating a new tag, the payload
had no labels and the backend silently attached nothing. It also used an
empty dependency array, so a stale tagValue dropped previously selected
tags from the emitted list. Emit the same mapping the row-toggle and
deleteTag handlers use, with the same dependencies.

Tested e2e on a local run: reproduced both variants on main (post created
with a modal-created tag saved zero TagsPosts rows; a pre-selected tag
plus a newly created one both dropped), then verified on this branch that
a modal-created tag attaches on the initial save, a pre-selected plus a
newly created tag both attach, and edit-and-resave keeps assignments
unchanged - all confirmed in the DB.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The auth middleware resolves the impersonate cookie to a UserOrganization
row, which pins both the user and the org, and returns before showorg is
ever read. Clicking an org in the switcher during impersonation therefore
wrote a cookie that nothing consumed: the page reloaded into the same org.

/user/change-org now moves the impersonation itself when a session is
active, rewriting the impersonate cookie to the target org's
UserOrganization id instead of setting showorg. Membership is resolved
through the existing userId_organizationId unique, and disabled or
non-existent memberships are rejected. Outside impersonation the endpoint
is unchanged.

Tested manually end-to-end: while impersonating a user who belongs to two
orgs, switching in both directions now lands in the selected org, and the
paywalled FREE org renders its billing screen as expected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drop Sentry.setUser entirely and carry the acting identity as plain tags
instead: user.email, user.id, organization, organization.id (backend
authenticated + frontend; public-API events keep org tags only, stripe
customer tag unchanged). Frontend clears all tags on logout.

Rationale: the user context (Contexts section) is display-only - not
searchable - and everything it held is already in the tags, which are
indexed and filterable. Dropping setUser also removes the id:/email:
prefixes Sentry bakes into its synthesized user tag, so tag values are
now the bare email/ids.

A bare 'user' tag was attempted (user: <email>) but Sentry silently
discards it - 'user' is a reserved tag key for the synthesized user tag
(https://docs.sentry.io/platforms/javascript/enriching-events/tags/).
The UI still groups user.email/user.id under a "user" heading, so
nothing is lost. Verified with a real event: user.email, user.id,
organization and organization.id all present with unprefixed values, no
User card in Contexts, reserved 'user' tag confirmed dropped.

Trade-offs accepted: issue "users affected" counts revert to IP-based
estimates, replays lose user attribution, and user.id:<x> search syntax
is replaced by the equivalent tag query.

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

Instagram rejects a media container when a collaborator handle cannot be
tagged, with error_subcode 2207018 ("Invalid user id"). handleErrors had no
branch for it, so it fell through to the generic BadBody fallback and the
customer's failure email read "An error occurred while posting to Instagram:
Unknown Error", with nothing pointing at the collaborator tag.

Map 2207018 to a bad-body message naming the three real causes: wrong handle,
private account, or collaborator invites disabled. instagram.standalone
delegates to this handleErrors, so both channel types are covered.

Meta's own error_user_msg is not surfaced instead: it comes back localized to
the connected account's language (Hebrew, in the reproduction), so it is not
usable as user-facing text.

Verified against a live Instagram channel by creating a media container with
the customer's exact handle: pre-fix "Unknown Error", post-fix the new message.
Reddit answers /api/submit with a 200 and a SUBREDDIT_NOEXIST error for
subreddits that do exist, intermittently: the same account, subreddit and
payload is rejected on one attempt and accepted on the next with nothing
changed in between.

Until e287a14 the submit response was not inspected for errors, so a
rejection crashed on `all.json.data.websocket_url` as a generic TypeError,
which the post workflow retried - the intermittent rejection cleared on a
retry and never reached the user. e287a14 started classifying every
submit error as BadBody, which is non-retryable, so the same intermittent
rejection now fails the post and notifies the user with a "that community
doesn't exist" message about a community they moderate.

Throw a retryable error for SUBREDDIT_NOEXIST only; every other submit
error keeps failing fast as BadBody. Resubmitting is safe: the armed
handshake in checkPostStatus still guards against a double post.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
feat/update contributing-guidelines for staging
@postiz-contribution postiz-contribution Bot added the staging:batch Aggregate PR shipping the staging batch to the default branch label Aug 17, 2026
@postiz-agent

postiz-agent Bot commented Aug 17, 2026 •

Copy link
Copy Markdown

✅ Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
✅ Open Source Security 0 0 0 0 0 issues
✅ Licenses 0 0 0 0 0 issues
✅ Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

egelhaus and others added 13 commits August 17, 2026 08:19
feat(build): add caching back to build workflow
The invoice preview in StripeService.prorate() passed proration_date
together with billing_cycle_anchor: 'now', which Stripe rejects
("You cannot specify proration_date when billing_cycle_anchor=now").
The error was swallowed and the billing page showed "Pay Today $0"
next to every upgrade, while the actual upgrade charged the correct
prorated amount.

Drop proration_date so the preview succeeds and the UI shows the amount
the customer will be charged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Temporal SDK logs outside of console: the TS side writes straight to
stderr and the native core prints directly, so Sentry's console logging
integration never sees lines like "Activity failed" or "Activity not
found on completion" - today they exist only in the Railway container
logs.

Install the Temporal Runtime once, before any worker is created, with a
DefaultLogger that prints in the SDK's own "<ts> [LEVEL] message {meta}"
format via console.error / console.log, and forward native core logs
(default filter: core WARN, other ERROR) into that same logger. Railway
keeps the same lines; Sentry now gets them too, so they can be searched
there (including read-only via the Sentry MCP) without touching prod.

Verified locally against the origin/main build with the same provoked
error: TS-side lines are byte-identical apart from timestamps; forwarded
native lines carry the same content in the SDK's structured format.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Pinterest's pin creation endpoint intermittently answers with
{"code":2787,"message":"Sorry! Something went wrong on our end."}.
It was unmapped in handleErrors, so the post failed immediately as a
non-retryable BadBody with the 'Unknown Error' placeholder, even though
identical requests succeed minutes later.

Map it to a retry (3 attempts, 5s apart) with a curated message so a
short Pinterest hiccup no longer fails the post, and if it persists the
user sees what actually happened instead of 'Unknown Error'.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
YouTube returns HTTP 403 with reason "forbidden" ("Access forbidden. The
request may not be properly authorized.") when the connected Google
account cannot upload to the selected channel. handleErrors had no mapping
for it, so it surfaced as the 'Unknown Error' placeholder. Map it as a
non-retryable bad-body with an actionable message; matched on the quoted
reason token so the plain word elsewhere in a body cannot trigger it.

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

Instagram returns (#10) "Requires instagram_content_publish permission to
manage the object" when the connected account was not granted the content
publishing permission for that Instagram account. handleErrors had no
mapping for it, so it surfaced as the 'Unknown Error' placeholder. Map it
as a non-retryable bad-body telling the user to reconnect and allow all
requested permissions for the account. Covers instagram-standalone too,
which delegates to the same handleErrors.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…he real update

Use proration_behavior: 'always_invoice' without billing_cycle_anchor in
the invoice preview, mirroring subscribe(), so "Pay Today" equals the
prorated amount Stripe actually invoices on upgrade.

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

strix-security Bot commented Aug 18, 2026 •

Copy link
Copy Markdown

Strix Security Review

6 open security findings on this PR:

1 resolved finding
Review summary

This re-review of the staging→main batch confirmed the previously reported security findings remain present in the current commit, since none of the affected files changed since the last review. The still-open issues are: "Frontend console logs exported to Sentry via enabled console log capture" (console log capture enabled with sendDefaultPii and enableLogs in the shared Next.js Sentry initializer), "Incomplete PII redaction allows user_id, org_id, and request_path to be sent to Sentry" (the sensitive-key regex still does not match these identifier keys), "PII disclosure to Sentry through forced NestJS console logging" (backend bootstrap forces NestJS logs through console with Sentry console capture enabled), and "User-linked orchestrator email logs exported to Sentry via forced console routing" (orchestrator forces NestJS and Temporal worker logs through console with Sentry console capture enabled). All are log/PII-hygiene issues at low severity. The newly-changed code in the commit delta (the Stripe load-failure UI handling, the account-activation redirect body-skip fix, and the Instagram container error mapping) was reviewed and introduces no new security issues. No prior findings were resolved by this commit.

Fixed the findings? re-run the review, or tag @strix-security in a PR comment to run a fresh review.

Updated for f1c3fa6.


Reviewed by Strix
Re-run review · Configure security review settings

@railway-app
railway-app Bot temporarily deployed to Postiz / staging September 18, 2026 21:17 Inactive
@railway-app
railway-app Bot temporarily deployed to Postiz / staging September 19, 2026 08:39 Inactive
@railway-app
railway-app Bot temporarily deployed to Postiz / staging September 20, 2026 10:20 Inactive
@railway-app
railway-app Bot temporarily deployed to Postiz / staging September 21, 2026 04:35 Inactive
@railway-app
railway-app Bot temporarily deployed to Postiz / staging September 21, 2026 10:36 Inactive
@railway-app
railway-app Bot temporarily deployed to Postiz / staging September 22, 2026 02:11 Inactive
github-actions Bot and others added 18 commits September 22, 2026 04:55
Resolved-by: claude-code-action

# Conflicts:
#	libraries/nestjs-libraries/src/integrations/social/mastodon.custom.provider.ts
Added a comparison between Postiz Cloud and Open-source versions, detailing features and differences. Updated sponsorship options for Postiz.
Enhance README with Postiz Cloud comparison and sponsorship
Resolved-by: claude-code-action

# Conflicts:
#	README.md
Resolved-by: claude-code-action

# Conflicts:
#	libraries/nestjs-libraries/src/integrations/social/reddit.provider.ts
Resolved-by: claude-code-action

# Conflicts:
#	.env.example
#	libraries/react-shared-libraries/src/translation/locales/ar/translation.json
#	libraries/react-shared-libraries/src/translation/locales/bn/translation.json
#	libraries/react-shared-libraries/src/translation/locales/de/translation.json
#	libraries/react-shared-libraries/src/translation/locales/en/translation.json
#	libraries/react-shared-libraries/src/translation/locales/es/translation.json
#	libraries/react-shared-libraries/src/translation/locales/fr/translation.json
#	libraries/react-shared-libraries/src/translation/locales/he/translation.json
#	libraries/react-shared-libraries/src/translation/locales/it/translation.json
#	libraries/react-shared-libraries/src/translation/locales/ja/translation.json
#	libraries/react-shared-libraries/src/translation/locales/ko/translation.json
#	libraries/react-shared-libraries/src/translation/locales/pt/translation.json
#	libraries/react-shared-libraries/src/translation/locales/ru/translation.json
#	libraries/react-shared-libraries/src/translation/locales/tr/translation.json
#	libraries/react-shared-libraries/src/translation/locales/vi/translation.json
#	libraries/react-shared-libraries/src/translation/locales/zh/translation.json
…error

fix(frontend): silence Unchecked runtime.lastError from extension messaging callbacks

This branch was successfully deployed

1 active deployment
Postiz / staging — f1c3fa6c Deployed Sep 25, 2026 by railway-app[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

guard:blocked Touches a guarded path and is awaiting sign-off staging:batch Aggregate PR shipping the staging batch to the default branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants