[Detail Bug] Ontology bulk authoring UI hides background jobs beyond the 20 most recent (and stops polling for active jobs)

Aperta
  • Qualcosa non va?
#36,030 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@detail-app ci sta già lavorando.

Dal 23/10/2026.

  • #36043 di @detail-app — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
java, typescript
Ambito
backend-api-design

Direzione di ricerca

Read useOntologyBulkJobs.ts, ontologyAPI.ts, and JobDAO.java, then trace how the jobs endpoint applies its limit and how the hook filters jobs and enables polling. Check the linked pull request #36043 for work already underway. Done means the selected glossary's jobs remain visible and active jobs continue to update even when they fall outside the initial list limit.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Detail Bug Report

https://app.detail.dev/org_3377c26d-da48-4ccd-b83a-22c542f4fe83/bugs/bug_67e063b2-99e6-4571-9c4b-99fb100fba08

Introduced in #28042 by @harshach on Aug 30, 2026

Summary

  • Context: The Ontology bulk authoring UI shows a "Background jobs" panel (via useOntologyBulkJobs) listing the bulk operations the current user has submitted for the selected glossary, polling for progress while jobs are queued/running.
  • Bug: The jobs list is fetched once with the default limit=20 over all glossaries of the calling user and then filtered client-side by glossary, so jobs of the selected glossary that fall outside the 20-most-recent window are silently dropped — and polling is gated on the filtered list, so a queued/running job outside the window never updates or reappears.
  • Actual vs. expected: The panel should show the selected glossary's jobs; instead it shows only those of the user's 20 most recent bulk jobs (across every glossary) that happen to belong to the selected glossary, and polling stops even when a job for that glossary is still queued/running.
  • Impact: A user who runs 20+ bulk jobs across multiple glossaries silently loses visibility of jobs for the selected glossary — including an active background import whose progress, status, and result cannot be seen from the UI while it runs (it does not reappear even after manual refresh, and only resurfaces days later if newer terminal rows age out of the 7-day retention window), with no way to cancel or download its result.

Code with Bug

// openmetadata-ui/src/main/resources/ui/src/components/OntologyExplorer/hooks/useOntologyBulkJobs.ts
const refreshJobs = useCallback(async () => {
  setIsLoading(true);
  setHasLoadError(false);

  try {
    const response = await listOntologyBulkJobs(); // <-- BUG 🔴 default limit=20, spans ALL glossaries
    setJobs(response.jobs.filter((job) => job.glossary.id === glossaryId)); // <-- BUG 🔴 client-side filter after truncation
  } catch {
    setHasLoadError(true);
  } finally {
    setIsLoading(false);
  }
}, [glossaryId]);

// ...

const hasActiveJobs = useMemo(
  () => jobs.some(isActiveOntologyBulkJob), // <-- BUG 🔴 computed from the truncated+filtered list
  [jobs]
);

usePollingEffect(refreshJobs, { enabled: hasActiveJobs }); // <-- BUG 🔴 polling never starts if the active job was dropped

// openmetadata-ui/src/main/resources/ui/src/rest/ontologyAPI.ts
export const listOntologyBulkJobs = async (limit = 20) => { // <-- BUG 🔴 hardcoded default
  const response = await APIClient.get<OntologyBulkJobList>(
    `${ONTOLOGY_BULK_PATH}/jobs`,
    { params: { limit } }
  );

  return response.data;
};

// openmetadata-service/src/main/java/org/openmetadata/service/jobs/JobDAO.java
@SqlQuery(
    "SELECT id, jobType, methodName, jobArgs, status, createdAt, updatedAt, createdBy, runAt, "
        + "progress, total, NULL AS result, error, message, cancelRequested, completedAt "
        + "FROM background_jobs WHERE createdBy = :createdBy "
        + "AND jobType = 'ONTOLOGY_BULK' ORDER BY createdAt DESC LIMIT :limit") // <-- BUG 🔴 no glossary predicate, truncates before the client filters
List<BackgroundJob> listOntologyBulkJobsByUser(
    @Bind("createdBy") String createdBy, @Bind("limit") int limit);

Explanation

  • The backend list endpoint (GET /v1/ontology/bulk/jobs) supports only a limit (default 20) and returns the user’s most recent ONTOLOGY_BULK jobs across all glossaries (SQL filters by createdBy + jobType only). There is no server-side glossary filter and no pagination.
  • The UI then filters the already-truncated response by job.glossary.id === glossaryId, so any jobs for the selected glossary that are older than the user’s 20 most recent jobs become unretrievable for the panel.
  • Polling is enabled only when hasActiveJobs is true, but hasActiveJobs is computed from the truncated+filtered jobs state. If the selected glossary’s only queued/running job is outside the 20-job window, polling never runs (and manual refresh hits the same endpoint), so the job stays invisible and never updates in the UI while still running server-side.

Codebase Inconsistency

  • The UI component using this hook expects a glossary-scoped background-jobs panel (useOntologyBulkJobs(glossary?.id) feeding OntologyBulkJobsPanel), but the backend API only provides a user-scoped list. The hook compensates with client-side filtering, which fails once server-side truncation occurs.

Recommended Fix

Request the maximum the server allows (listOntologyBulkJobs(100)) and/or add a glossary filter server-side (e.g. a glossaryId query param resolved in listOntologyBulkJobsByUser) so the panel's list is complete for the selected glossary. For the polling gate, base enabled on information that is not destroyed by the truncation — e.g. keep polling while any submission for this glossary may still be in flight (the hook knows when submitOntologyBulkOperation returned ExecutionMode.Background), or have the list endpoint expose the caller's active-job count independent of the page window.

History

This bug was introduced in commit 7b1bc6b6a1 (feat(rdf): SPARQL playground, MCP knowledge-graph tools, insights endpoints (#28042), 2026-08-29). The commit created the entire Ontology bulk-authoring feature in one pass — useOntologyBulkJobs.ts, the listOntologyBulkJobs API in ontologyAPI.ts, OntologyBulkResource.java, and JobDAO.listOntologyBulkJobsByUser — and baked the faulty design in from day one: a hardcoded limit = 20 default on the client and a server SQL that filters only by createdBy and jobType = 'ONTOLOGY_BULK' with no glossary predicate, forcing the hook to filter client-side over an already-truncated, cross-glossary list and gating polling on that filtered result.

Lingua principale
TypeScript
Stelle
15.4k
Fork
2.4k
Merge medio
1g 2h
PR unite (30g)
693

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di open-metadata/OpenMetadata

Tutte le issue di open-metadata/OpenMetadata

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.