fix: 670 pipedream actor tagging - #25
Merged
daveomri merged 6 commits intoAug 18, 2026
Merged
Conversation
daveomri
marked this pull request as ready for review
July 29, 2026 16:54
drobnikj
approved these changes
Aug 14, 2026
drobnikj
left a comment
Member
There was a problem hiding this comment.
One imporovement otherwise fine
…nto fix/670-pipedream-actor-tagging
daveomri
changed the base branch from
develop
to
fix/668-pipedream-retest-fixes
August 18, 2026 14:54
daveomri
merged commit Aug 18, 2026
a2fa46d
into
apify:fix/668-pipedream-retest-fixes
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
latest). A build number like0.1.2was rejected by both the run-time validation and the schema resolution, even though Apify's run API accepts either.latestmay not point to the newest or a working build (seen onapify/facebook-posts-scraper), so users had no way to target a specific version.Reported in Pipedream retest #612.
What changed
apify.app.mjsbuildTagdropdown 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.resolveBuildId(actorId, buildRef): resolves a build tag or number to a build id. Tries the tag map fromgetActorfirst, then falls back to matchingbuildNumberinlistBuilds. Throws a single clear error when neither matches.getBuild()now delegates toresolveBuildIdand just fetches the build.actions/run-actor/run-actor.mjs(0.0.7→0.0.12)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:fixclean on both changed files (pre-existingaction-annotationserrors inget-kvs-record/run-taskare unrelated and untouched).buildNumber,buildNumberInt,id,status) confirmed against the Apify REST API docs; the bundledapify-clienttype under-declares the list item, so we rely on the API response.develophas norun-actor.test.mjs(added by 669), so no test file added here to avoid an add/add conflict. Live smoke test done viapd publish+ running the step in a workflow: tag (latest) and typed build number both load the input schema and run.Closes #670