Skip to content

Conversation

@JuliRossi
Copy link
Collaborator

Purpose

Fetching Scheduled Actions

Approach

  • Created the call
  • Created hook with tanstack (Not sure if it's needed in this case)
  • Rename a few files
  • Updated generating script to be able to create multiple schedule actions while generating entries

Testing steps

Created 200+ scheduled actions (entries and assets) with the generating script. Make sure the app can handle it

Grabacion.de.pantalla.2025-12-29.a.las.4.13.15.p.m.mov

@JuliRossi JuliRossi requested a review from a team as a code owner December 29, 2025 19:33
Copy link
Collaborator

@FBanfi FBanfi left a comment

Choose a reason for hiding this comment

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

Looks great to me!! 💯 I added two non-blocking comments

'environment.sys.id': sdk.ids.environment,
'sys.status[in]': 'scheduled',
'order': 'scheduledFor.datetime',
'limit': 500
Copy link
Collaborator

Choose a reason for hiding this comment

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

Even though there is a 500 limit at creation time for scheduled actions, we are only getting/fetching them here, so I would remove this limit in the query. This would allow us to decouple from the 500 hardcoded value in case in some future it changes!
Since you have already implemented the solution with TanStack, the batch handling would be done automatically if this value some day is higher! 😎

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Tested this and unfortunately if you don't specify a limit number, by default the CMA limits it automatically to 100 actions. So, I think we still need to clarify the limit.

Comment on lines +19 to +20
const { data, isFetching, error, refetch } = useQuery<FetchScheduledActionsResult, Error>({
queryKey: ['scheduledActions', sdk.ids.space, sdk.ids.environment],
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just a heads up that if we use TanStack to fetch the scheduled actions as it is right now in the code, we are using the same configuration of the Query Client used for the fetch of the entries (so we are using the same stale time, gcTime, retries and retries delay).
I don't know if we want to have different parameters for the fetch of the scheduled actions. If we are ok using the same ones, just ignore this comment! 😁

// QueryClient
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: CACHE_CONFIG.STALE_TIME_MS,
      gcTime: CACHE_CONFIG.CACHE_TIME_MS, // gcTime replaces cacheTime in v5
      refetchOnWindowFocus: CACHE_CONFIG.REFETCH_ON_WINDOW_FOCUS,
      retry: 2, // Retry failed requests 2 times
      retryDelay: 3000,
    },
  },
});

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks for bringing this up so I can give some though into it! I think it make sense to keep it consistent across queries.

@JuliRossi JuliRossi merged commit 7d5ba37 into content-production-dashboard Jan 5, 2026
6 checks passed
@JuliRossi JuliRossi deleted the maps-127 branch January 5, 2026 17:08
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.

3 participants