Skip to content

fix: 670 pipedream actor tagging - #25

Merged
daveomri merged 6 commits into
apify:fix/668-pipedream-retest-fixesfrom
daveomri:fix/670-pipedream-actor-tagging
Aug 18, 2026
Merged

fix: 670 pipedream actor tagging#25
daveomri merged 6 commits into
apify:fix/668-pipedream-retest-fixesfrom
daveomri:fix/670-pipedream-actor-tagging

Conversation

@daveomri

@daveomri daveomri commented Jul 21, 2026

Copy link
Copy Markdown
Collaborator

Why

  • The Run Actor "Build" field only accepted build tags (e.g. latest). A build number like 0.1.2 was rejected by both the run-time validation and the schema resolution, even though Apify's run API accepts either.
  • latest may not point to the newest or a working build (seen on apify/facebook-posts-scraper), so users had no way to target a specific version.
  • The Build dropdown listed bare tag names with no version context.

Reported in Pipedream retest #612.

What changed

apify.app.mjs

  • buildTag dropdown now labels each tag with its build number (e.g. latest (0.0.354)) and returns [] before an Actor is selected. Build numbers can still be typed as free text, so the dropdown is a convenience, not a whitelist.
  • Added resolveBuildId(actorId, buildRef): resolves a build tag or number to a build id. Tries the tag map from getActor first, then falls back to matching buildNumber in listBuilds. Throws a single clear error when neither matches.
  • getBuild() now delegates to resolveBuildId and just fetches the build.

actions/run-actor/run-actor.mjs (0.0.70.0.12)

  • Replaced the inline tag-only validation block with one resolveBuildId(actorId, buildTag) call, so build numbers pass validation and the tag/number logic lives in one place.

Testing

  • cd components/apify && npm run lint:fix clean on both changed files (pre-existing action-annotations errors in get-kvs-record/run-task are unrelated and untouched).
  • Build-list item shape (buildNumber, buildNumberInt, id, status) confirmed against the Apify REST API docs; the bundled apify-client type under-declares the list item, so we rely on the API response.
  • develop has no run-actor.test.mjs (added by 669), so no test file added here to avoid an add/add conflict. Live smoke test done via pd publish + running the step in a workflow: tag (latest) and typed build number both load the input schema and run.

Closes #670

obrazek obrazek

@daveomri
daveomri marked this pull request as ready for review July 29, 2026 16:54

@JanHranicky JanHranicky left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@drobnikj drobnikj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One imporovement otherwise fine

Comment thread components/apify/apify.app.mjs
@daveomri
daveomri changed the base branch from develop to fix/668-pipedream-retest-fixes August 18, 2026 14:54
@daveomri daveomri self-assigned this Aug 18, 2026
@daveomri
daveomri merged commit a2fa46d into apify:fix/668-pipedream-retest-fixes Aug 18, 2026
1 check passed
drobnikj pushed a commit that referenced this pull request Sep 3, 2026
…ages (PipedreamHQ#21684)

* feat(slack_v2): read direct messages by user ID + deprecate List Messages

Iterated against the MCP eval suite (evals/slack_v2); this ships the fixes the
evals surfaced. Suite green on Sonnet 5 (3/3, pass^2) after the change.

- slack_v2.app.mjs: eval PipedreamHQ#36 ("read my DMs with myself") failed — the read tools
  forwarded a `U…` user id straight to conversations.history, which only accepts a
  conversation id and answered channel_not_found (writing to a DM already worked via
  chat.postMessage auto-open). Added openConversation() (conversations.open) and made
  resolveChannelId open the DM for a user id — the read-side counterpart to posting —
  so history, thread-replies, and reactions now accept a user id. Also made the id
  regexes case-sensitive (Slack ids are uppercase-only) so an all-alphanumeric
  lowercase channel NAME isn't misclassified as an id. PipedreamHQ#36 FAIL→PASS. [shared by 10 actions]
- get-channel-history: description + `channel` prop now document reading a DM by user
  id.  [minor]
- list-messages: the legacy twin of Get Channel History was winning routing on the
  channel-read evals (#3/#25 warned expected_tools_missing, precision 0%). Renamed to
  "List Messages (Deprecated)" and steered to Get Channel History (name + first line are
  the tool-search retrieval key); run() unchanged, existing workflows still work.
  #3/#25/PipedreamHQ#36 → pass^2 3/3.  [patch]
- get-thread-replies, browse-files, set-channel-topic, get-channel-details,
  invite-user-to-channel, delete-message, add-reaction, edit-message,
  list-members-in-channel: version-only bumps for the shared resolveChannelId change.  [patch]

App package.json bumped 0.7.0 → 0.8.0.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(slack_v2): bump remaining component versions for shared app-file change

The slack_v2.app.mjs change in this PR touches a shared dependency file, so CI's
version check flags every component in the app. Patch-bump the remaining actions and
sources (the resolveChannelId consumers were already bumped in the prior commit) to
satisfy the check. No behavior change in these files.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* add ai-optimized marker

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants