fix: send webhooks the DB post id via post.workflow.v1.1.2

[giladresisi]

What kind of change does this PR introduce?

Bug fix (orchestrator, post workflow / organization webhooks). Every post-publish webhook (Settings → Webhooks) delivered a body of literally [] instead of the published post: the post workflow passed postsResults[0].postId — the id the platform returned (e.g. a Telegram message number) — to the sendWebhooks activity, while getPostByForWebhookId matches on our DB Post.id, so the lookup always returned an empty array. Since deployed workflow files are frozen, this adds post.workflow.v1.1.2 — an exact copy of the deployed v1.1.1 except the webhook call now passes postsList[0].id (the DB id already used by changeState/updatePost) and the repeat-post startChild points at itself — and flips all start sites (posts.service.ts start call + workflow_type log labels, post.activity.ts signalWithStart, workflows/index.ts export) to postWorkflowV112. The sendWebhooks activity, its signature, and all older workflow versions (v1.1.1 included) are untouched, so in-flight workflows keep running.

Originally this PR introduced v1.1.1, but v1.1.1 was since taken by the heartbeat-timeout work on staging (#1996) and is already deployed without the webhook fix, so the branch was merged with staging (adopting its v1.1.1 as-is) and the fix re-cut as v1.1.2.

Why was this change needed?

A customer reported their webhook endpoint receiving "the same webhook again and again", each delivery an empty array, and never a real post payload. The bug affects every workflow version to date, so no org webhook has ever received actual post data. Fixing it in a new workflow version follows the repo rule that deployed workflow files are frozen.

Other information:

Same file set and pattern as previous version bumps. The repeated deliveries the customer saw are the activity's normal retries; the payload being [] on every attempt was the actual bug.

QA

1. In Settings → Webhooks, add a webhook pointing at a publicly reachable listener that prints request bodies (localhost is blocked by the SSRF guard unless DISABLE_SSRF_PROTECTION=true; a cloudflared/ngrok tunnel works).
2. Schedule a post a minute ahead on any connected channel and let it publish.
3. The listener should receive a POST whose body is a JSON array with the post object — id, content, publishDate, releaseURL, state PUBLISHED, and an integration block — instead of [].
4. Confirm the Temporal UI shows the run as postWorkflowV112 and that older in-flight runs still complete.

Tested end to end against a real connected Telegram channel (as the v1.1.1 cut of this fix; v1.1.2 is the identical 3-line change re-applied on top of the deployed v1.1.1): drove the old and fixed workflows on identical posts; the pre-fix run delivered [] to the listener and the post-fix run delivered the full post JSON. Also verified via Temporal workflow history that the sendWebhooks input changed from the platform id to the DB post id, and that backend + orchestrator builds pass after the staging merge.

Checklist:

Put a "X" in the boxes below to indicate you have followed the checklist;

• I have read the CONTRIBUTING guide.
• I have signed the Contributor License Agreement (CLA) (ICLA for individuals, CCLA for entities).
• I confirm I have not used AI to submit this PR or generate code for it.
• I checked that there were no similar issues or PRs already open for this.
• This PR fixes just ONE issue
• I have filled in the QA section above with real steps to verify this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JkiuuMQcG1QRkbagfSkBtb

[strix-security]

Strix Security Review

No security issues found.

_{Updated for eddf713.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[postiz-agent]

✅ 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.

[giladresisi]

Superseded by #2087, which fixes the same empty-payload bug inside the sendWebhooks activity (releaseId fallback) instead of a new workflow version, so it also covers in-flight and repeat-post runs and avoids further workflow version collisions.