Skip to content

feat: use faster refresh interval when jobs are processing#94

Open
tifa2UP wants to merge 1 commit intofeat/documents-processing-calloutfrom
feat/dynamic-refresh-interval-processing
Open

feat: use faster refresh interval when jobs are processing#94
tifa2UP wants to merge 1 commit intofeat/documents-processing-calloutfrom
feat/dynamic-refresh-interval-processing

Conversation

@tifa2UP
Copy link
Member

@tifa2UP tifa2UP commented Jan 17, 2026

Summary

Improves UX by refreshing data more frequently (every 1.5s instead of 15s) ONLY when jobs are being processed, so users see updates faster.

Changes

  • useDocuments hook: Added isProcessing parameter that controls refresh interval
  • useJobsStatus hook: Uses dynamic refetchInterval that speeds up when pending jobs are detected
  • Documents page: Passes isProcessing state to useDocuments

Behavior

State Refresh Interval
Jobs processing 1.5 seconds
Idle (no jobs) 15 seconds

This ensures the UI updates quickly while documents are being processed, then returns to normal polling to reduce unnecessary requests.


Note: This PR is based on feat/documents-processing-callout and should be merged after it.

Greptile Summary

This PR implements adaptive polling intervals to improve UX when jobs are processing. When pending jobs are detected, the refresh interval speeds up from 15s to 1.5s across both job status checks and document queries.

Key Changes:

  • useJobsStatus now uses a dynamic refetchInterval function that checks for pending jobs
  • useDocuments accepts an isProcessing parameter to control its refresh interval
  • Both hooks refresh every 1.5s during processing, returning to 15s when idle

Minor improvement suggested:

  • Extract magic numbers (1_500, 15_000) as named constants to follow clean code guidelines

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The changes are well-structured and implement a straightforward optimization. The logic is sound: dynamic polling intervals based on job status will improve UX without introducing bugs. The only suggestion is a non-critical style improvement regarding magic numbers.
  • No files require special attention

Important Files Changed

Filename Overview
apps/web/src/app/app.agentset.ai/(dashboard)/[slug]/[namespaceSlug]/documents/use-pending-jobs.ts Implements dynamic refetch interval for job status polling; magic numbers should be extracted as constants for better maintainability
apps/web/src/app/app.agentset.ai/(dashboard)/[slug]/[namespaceSlug]/documents/use-documents.ts Added isProcessing parameter to control refetch interval; implementation is straightforward and correct
apps/web/src/app/app.agentset.ai/(dashboard)/[slug]/[namespaceSlug]/documents/page.client.tsx Derives isProcessing state from jobs status and passes it to useDocuments hook; clean integration

Context used:

  • Context from dashboard - Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing ... (source)

@vercel
Copy link

vercel bot commented Jan 17, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
app-agentset-ai Ready Ready Preview, Comment Jan 17, 2026 3:37pm

Request Review

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

3 files reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

Comment on lines +44 to +47
refetchInterval: (query) => {
const hasPending = (query.state.data?.records.length ?? 0) > 0;
return hasPending ? 1_500 : 15_000;
},
Copy link
Contributor

Choose a reason for hiding this comment

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

style: magic numbers 1_500 and 15_000 should be extracted as named constants at the top of the file

Suggested change
refetchInterval: (query) => {
const hasPending = (query.state.data?.records.length ?? 0) > 0;
return hasPending ? 1_500 : 15_000;
},
const REFRESH_INTERVAL_PROCESSING = 1_500;
const REFRESH_INTERVAL_IDLE = 15_000;
// ...
refetchInterval: (query) => {
const hasPending = (query.state.data?.records.length ?? 0) > 0;
return hasPending ? REFRESH_INTERVAL_PROCESSING : REFRESH_INTERVAL_IDLE;
},

Context Used: Context from dashboard - Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing ... (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/src/app/app.agentset.ai/(dashboard)/[slug]/[namespaceSlug]/documents/use-pending-jobs.ts
Line: 44:47

Comment:
**style:** magic numbers `1_500` and `15_000` should be extracted as named constants at the top of the file

```suggestion
const REFRESH_INTERVAL_PROCESSING = 1_500;
const REFRESH_INTERVAL_IDLE = 15_000;

// ...

        refetchInterval: (query) => {
          const hasPending = (query.state.data?.records.length ?? 0) > 0;
          return hasPending ? REFRESH_INTERVAL_PROCESSING : REFRESH_INTERVAL_IDLE;
        },
```

**Context Used:** Context from `dashboard` - Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing ... ([source](https://app.greptile.com/review/custom-context?memory=ae3f5924-b837-4792-9dae-0bd929e9f8dd))

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.

- Add isProcessing parameter to useDocuments hook
- Update useJobsStatus to use dynamic refetchInterval based on pending jobs
- Pass isProcessing from jobsStatus to useDocuments in page component
- Refresh every 5s when processing, 15s when idle
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.

1 participant