SocialPost ExecModule Migration

Overview

SocialPostModule is a retired compatibility module. It is hidden from Workflow Studio and never sends content to a social provider.

The former implementation could generate a local providerPostId and report published without loading the referenced SocialPost, resolving a real provider account, or making a provider request. Version 2.0 removes that false-success path. The class remains loadable so saved workflows can be inspected and migrated, but every execution fails closed with MODULE_RETIRED.

Usage

Do not add SocialPostModule to new workflows. For each saved task that uses it:

1. Identify the intended provider and content shape.
2. Select the dedicated provider ExecModule.
3. Bind a least-privilege IntegrationAccount through the generated ExecModuleConfig.authConfig.integrationAccount relationship.
4. Map the old content, reply, link, media, or scheduling fields to the provider module's documented inputs.
5. Review the provider-specific idempotency and ambiguous-write policy.
6. Test in an authorized provider sandbox or non-production account before replacing the production workflow task.

Inputs

The compatibility shell recognizes the old input names only so the saved task remains readable. It does not load or transmit either value.

Name	Type	Required	Behavior
socialPostId	UUID	No	Ignored. No SocialPost record is loaded.
templateContext	object	No	Ignored. No template is rendered and no content is sent.

Outputs

Name	Type	Description
status	string	Always error.
error.code	string	Always MODULE_RETIRED.
error.message	string	Safe migration guidance.
error.retryable	boolean	Always false; repeating the same task cannot publish content.
error.migrationTargets	array	Dedicated provider module class names available for migration.

No provider identifier, permalink, publication timestamp, or success status is produced.

IntegrationAccount Requirements

SocialPostModule does not accept, load, or decrypt credentials. Legacy channelAccountId values are ignored.

Create a provider-specific IntegrationAccount only after choosing the replacement module. Store secrets in encrypted IntegrationAccount fields and bind the relationship through normalized ExecModuleConfig; never place access tokens, client secrets, passwords, or signed URLs in input or module data.

Configuration

The following legacy fields remain visible only on direct metadata lookup so old configurations can be recognized:

Field	Legacy purpose	Version 2.0 behavior
channelAccountId	Selected a ChannelAccount.	Never resolved.
postTemplateId	Selected a message template.	Never loaded.
shorteningProvider	Requested URL shortening.	Never invoked.
trackLinks	Requested tracking parameters.	Never invoked.

There is no configuration that re-enables generic publishing.

Operations

Version 2.0 implements one deterministic compatibility operation: reject execution and return migration targets.

Replacement	Intended provider behavior
XPostModule	Create X text, reply, quote, and pre-uploaded-media Posts.
FacebookPagePostModule	Create immediate, draft, scheduled, link, or remote-photo Facebook Page posts.
LinkedInCompanyShareModule	Publish an authorized LinkedIn organization share.
InstagramPublishModule	Publish supported Instagram Business media.

Use the current Social Media ExecModules guide to choose the provider path.

Errors and Failure Modes

Failure	Meaning	Recovery
MODULE_RETIRED	The workflow still references the generic stub. No provider call occurred.	Replace the task with a dedicated provider module.
Replacement validation error	Provider-specific content or account data is invalid.	Correct the named input or IntegrationAccount field.
Replacement ambiguous write	A timeout, HTTP 429, or provider 5xx leaves commit state unknown.	Inspect provider state before a deliberate retry; do not assume the post failed.

The compatibility response never includes legacy input values, credentials, or provider response data.

Example

Legacy input:

{
  "templateContext": {
    "content": "Release notes are live",
    "platform": "twitter"
  }
}

Expected result:

{
  "status": "error",
  "error": {
    "code": "MODULE_RETIRED",
    "message": "SocialPostModule is retired; replace it with a dedicated provider ExecModule",
    "retryable": false,
    "migrationTargets": [
      "XPostModule",
      "FacebookPagePostModule",
      "LinkedInCompanyShareModule",
      "InstagramPublishModule"
    ]
  }
}

For that example, migrate to XPostModule, bind a READY X IntegrationAccount, and map templateContext.content to the replacement module's text input.

Notes

• Pagination: not applicable; the compatibility shell performs no read or write.
• Limits: legacy input is not parsed, rendered, shortened, or transmitted.
• Idempotency: repeated execution returns the same failure shape and has no external side effect.
• API constraints: no provider API is called. Provider-specific constraints apply only after migration.
• Destructive behavior: none. The compatibility shell cannot publish, update, or delete posts.
• Observability: a bounded warning records that execution was blocked; legacy content and credentials are not logged.
• Runtime boundary: source changes affect deployed catalog discovery only after the ValkyrAI application runtime is separately deployed. Until then, use the live /v1/modules/metadata response as the Workflow Studio baseline.