feat(apify): Prefill values from the input schema by matyascimbulka · Pull Request #7 · apify/pipedream

matyascimbulka · 2025-09-03T08:57:12Z

Links to this issue.

Improves the generation of the input props based on the input schema fetched from the Platform. When input field in the input schema doesn't have a default value the prefill value is used instead. Also all boolean fields are set to false unless changed by default or prefill setting.

JanHranicky

Looks good, leaving a small comment 🤠, but approving! 🫡

JanHranicky · 2025-09-04T08:15:45Z

+        if (defaultValue) {
          if (props[key].type !== "object") {
-            props[key].default = value.default;
+            props[key].default = defaultValue;
+
+            if (props[key].type === "string[]" && value.editor === "requestListSources") {
+              props[key].default = defaultValue.map((request) => request.url);
+            }
          }
+
+          props[key].description += ` Default: \`${JSON.stringify(defaultValue)}\``;
        }


Will this condition run for falsy values like 0 or false ?🤔

You're right. I think it would be better to check that the defaultValue isn't undefined.

drobnikj · 2025-09-04T13:21:11Z


-        if (value.default) {
-          props[key].description += ` Default: \`${JSON.stringify(value.default)}\``;
+        const defaultValue = value.default ?? value.prefill;


I also wrote it into the issue
If the Actor has an input schema, let's use prefill values to prefill values in the form

I get that this is confusing, that in the Input Schema we called it prefill, but on the pipedream they call it default value, not sure if they have something like prefill.

The reson it that based on doc https://docs.apify.com/platform/actors/development/actor-definition/input-schema/specification/v1#prefill-vs-default-vs-required
the prefill is to guide the user on what to fill, what is exactly we wanted to do in the Run Actor action, get user idea , what to fill it by example.

Ok, that make sense.

* feat(apify): Show list of built tags in actor run action * feat(apify): Allow selecting actor search source for run Actor action and change how Actor or task name is displayed * feat(apif): Remove wait for finish prop in run Actor action * fix(apify): Fix PR issues * fix(apif): Fix PR issues * fix(scrape-single-url): return the only dataset item after the run is finished (#3) * fix(scrape-single-url): return the only dataset item after the run is finished * fix(scrape-single-url): version up * fix(scrape-single-url): version up * fix(scrape-single-url): version up * fix(scrape-single-url): introduce a job status constant, expand a list of terminal statuses to stop the loop * fix(scrape-single-url): import constants from package, decrease delay in between calls * Migrate to use Apify client (#6) * feat(apify): Replace Axios with Apify client * fix(general): adding custom headers to client()=> preserve whole config to be passed to Axios later * feat(general): add linter script * fix(apify-get-dataset-items): a function for getting items and parsing of a result * fix(apify-run-actor): working sync and async, dynamic input schema injection, KVS output retrieval tested only string * fix(general): change maxResults for limit as an input field * fix(run-task-sync): move items retrieval to the component, add waitSecs determined by input or plan to prevent blunt timeout error, have the item retrieval logic be connected to run status, clean return value * fix(apify-scrape-single-url): incorporate timeouts, rework the whole API interaction logic * fix(apify-set-key-value-store-record): detection of content type, fixed API interaction * fix(apify-scrape-single-url): remove waiting timeout, return only dataset item, remove extra input fields connected to WCC run * fix(apify-run-actor): success message * fix(apify-run-task-synchronously): remove waiting for run to finish timeout * fix(app): remove paidPlan input filed config --------- Co-authored-by: Matyas Cimbulka <matyas.cimbulka@apify.com> * fix(apify-get-dataset-items) 6: change input parameters (#8) * chore(apify): Bump component versions * chore: Sync upstream repo (#9) * feat(apify): Prefill values from the input schema (#7) * Revert "chore: Sync upstream repo (#9)" This reverts commit cd804ba. * Revert "chore(apify): Bump component versions" This reverts commit 6040822 which for some reason bumped version of the wrong components. * fix(apify): Fix build tag * fix(apify): Address issues in run task synchronously action * feat(apify): Add default crawler type to scrape single url * fix(apify): Address issues from PR * chore(apify): Change component versions * fix(apify): Fix run Actor action * fix(apify): Fix run get dataset items action * fix(apify): Fix typos for PR --------- Co-authored-by: Oleksandra Valko <oleksandra.valko@apify.com>

…1826) * feat(dappier): AI-optimized Dappier action set for MCP (real-time search, recommendations, analytics) Initial AI-optimized Dappier components for the MCP tool surface, covering issue PipedreamHQ#21660 (real-time web search, AI content recommendations, data-model querying) plus the four Analytics API endpoints. Iterated against the MCP eval suite (evals/dappier) — 9/10 green on Sonnet 5 (trials: 1); the one failure is an upstream HTTP 500 on POST /app/v2/search, not a component defect. agent-audit: 100/100. - search-real-time-data (new, 0.0.1): real-time web/data search via a Dappier AI model (am_ id); returns a synthesized answer. Eval #9 passes. - get-ai-recommendations (new, 0.0.1): AI-ranked content recommendations for a data model (dm_ id); optional additive `fields` projection trims large article payloads. Eval #10 blocked by an upstream 500 (server-side). - get-ask-ai-analytics (new, 0.0.1): aggregate Ask AI widget analytics. Evals #1/#4/#5 pass. - get-ask-ai-logs (new, 0.0.1): raw Ask AI conversation logs with page/limit pagination + paging guidance. Evals #2/#6 pass. - get-sponsored-conversations-analytics (new, 0.0.1): sponsored-conversation (ad campaign) analytics. Eval #7 passes. - get-session-intelligence (new, 0.0.1): session intent/topic breakdowns. Evals #3/#8 pass. - dappier.app.mjs: shared analytics prop definitions + GET request methods. - common/utils.mjs: validateDateRange (365-day cap) + pluckFields projection helper. - common/constants.mjs: analytics interaction types, range + page-size bounds. App package.json bumped 0.0.1 -> 0.1.0 (minor -- new actions). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(dappier): add trailing newline to package.json (eol-last) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(dappier): address review — numArticlesRef max, own-prop projection, date default wording - get-ai-recommendations: numArticlesRef description said max 1000 but schema is max 100; corrected the doc. - common/utils.mjs: pluckFields now uses Object.hasOwn so a requested field name that collides with an inherited prop (e.g. toString) is not copied; own result fields still are. - dappier.app.mjs: reworded startDate default from the brittle/off-by-one '7 days before today' to 'the last 7 days (UTC), i.e. today and the six prior days', matching observed API behavior. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(dappier): resolve one-sided analytics date windows before sending Verified against the live API: omitting either start_date or end_date makes Dappier reset BOTH bounds to its default trailing-7-day window, silently discarding the bound the caller supplied — so a one-sided range returned the wrong period. resolveDateRange() now fills the missing bound (missing end -> today UTC; missing start -> 6 days before the end) and always sends both, so a supplied bound is honored; both-omitted still defers to the API default. All four analytics actions use it; start/end prop docs updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(dappier): match analytics date-range cap to the API (inclusive days) Probed the live API: it accepts a 364-day start/end difference (365 inclusive days) and returns 400 at a 365-day difference (366 inclusive days). validateDateRange used '> 365 days difference', so a 365-day-difference window slipped past the fail-fast and hit a raw API 400. Now counts inclusive days (difference + 1) and caps at 365, matching the API exactly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(dappier): note session_intelligence wrapper in get-session-intelligence description The API nests all six breakdowns under a single top-level `session_intelligence` object (verified live). The description listed them as if they were root keys, so an agent would look for them at the root and miss the `session_intelligence.` prefix. Description-only; no behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(dappier): use camelCase widgetId in session-intelligence example The example told the agent to pass `widget_id`, but the input prop is `widgetId` (run() maps it to the `widget_id` query param). Match the example to the prop the agent actually sets. Description-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(dappier): use camelCase prop names in remaining action examples Same fix as get-session-intelligence, applied to the sibling descriptions: the agent-facing 'Example:' hints used API param names (start_date, end_date, campaign_id, data_model_id) instead of the camelCase input props (startDate, endDate, campaignId, dataModelId). API-mapping mentions stay snake_case. Description-only; no behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(dappier): camelCase input-guidance for model-id props The 'Provide a ...' input guidance used API param names — get-ai-recommendations said 'Provide a data_model_id' (prop is dataModelId) and search-real-time-data said 'Provide an ai_model_id' (prop is aiModelId). Use the camelCase input keys; snake_case is retained only where describing the API request mapping (query param / path template). Description-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Adding missing dependencies field --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: GTFalcao <gtfalcao96@gmail.com>

feat(apify): Improve generating props from input schema

8b89b6a

matyascimbulka self-assigned this Sep 3, 2025

matyascimbulka requested review from JanHranicky, drobnikj and protoss70 September 3, 2025 08:57

feat(apify): Bump version number for run Actor action

4b64f79

matyascimbulka force-pushed the feat/2-prefill-values-from-input-schema branch from 5870118 to 4b64f79 Compare September 3, 2025 09:55

feat(apify): Bump package.json version

3e6b359

JanHranicky approved these changes Sep 4, 2025

View reviewed changes

drobnikj requested changes Sep 4, 2025

View reviewed changes

oleksandravalko and others added 2 commits September 4, 2025 18:11

fix(apify-get-dataset-items) 6: change input parameters (#8)

185efb1

feat(apify): Prefer prefill value over default value

c97c27a

matyascimbulka requested a review from drobnikj September 5, 2025 06:44

drobnikj approved these changes Sep 8, 2025

View reviewed changes

matyascimbulka added 2 commits September 8, 2025 15:04

chore: Sync upstream repo (#9)

cd804ba

merge: Merge master into feature branch

90b4ef1

matyascimbulka merged commit 168194a into master Sep 8, 2025
6 of 7 checks passed

matyascimbulka deleted the feat/2-prefill-values-from-input-schema branch September 8, 2025 13:31

Navigation Menu

Uh oh!

feat(apify): Prefill values from the input schema - #7

feat(apify): Prefill values from the input schema#7
matyascimbulka merged 7 commits into
masterfrom
feat/2-prefill-values-from-input-schema

matyascimbulka commented Sep 3, 2025 •

edited

Loading

Uh oh!

JanHranicky left a comment

Uh oh!

JanHranicky Sep 4, 2025

Uh oh!

matyascimbulka Sep 5, 2025

Uh oh!

drobnikj Sep 4, 2025

Uh oh!

matyascimbulka Sep 5, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

matyascimbulka commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JanHranicky left a comment

Choose a reason for hiding this comment

Uh oh!

JanHranicky Sep 4, 2025

Choose a reason for hiding this comment

Uh oh!

matyascimbulka Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

drobnikj Sep 4, 2025

Choose a reason for hiding this comment

Uh oh!

matyascimbulka Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

matyascimbulka commented Sep 3, 2025 •

edited

Loading