Skip to content

fix(crawler-ws): Improve pre-checks on zk-getdata and improve logging - #95

Open
Wisienkas wants to merge 3 commits into
devfrom
fix/improve-missing-zk-getdata-error-flow
Open

fix(crawler-ws): Improve pre-checks on zk-getdata and improve logging#95
Wisienkas wants to merge 3 commits into
devfrom
fix/improve-missing-zk-getdata-error-flow

Conversation

@Wisienkas

Copy link
Copy Markdown
Contributor

No description provided.

@Wisienkas
Wisienkas requested a review from fmendezh July 31, 2026 13:26
@Wisienkas Wisienkas self-assigned this Jul 31, 2026

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

This PR improves the coordinator’s ZooKeeper status reads to better tolerate transient races (e.g., nodes disappearing or being cleared during concurrent cleanup) and refines how those conditions are logged, reducing unnecessary failures when assembling dataset process status.

Changes:

  • Handle empty crawl-info ZK node data as a transient cleanup race and treat the dataset as not currently being processed.
  • Make getState() more robust to missing/vanishing nodes and to invalid enum values, returning null state instead of failing.
  • Improve batch status retrieval logging by distinguishing expected ZooKeeper-related failures from unexpected errors.
Suppressed comments (1)

crawler-coordinator/src/main/java/org/gbif/crawler/DatasetProcessServiceImpl.java:395

  • The WARN log in getState() drops the exception stack trace by logging e.toString() into a placeholder. For unexpected failures (i.e., not the benign concurrent-deletion case), keeping the Throwable as the last argument will preserve the stack trace and improve diagnosability.
        LOG.warn(
          "Could not read process state for dataset [{}] at path [{}], treating as unknown: {}",
          datasetKey, path, e.toString());
      }

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +139 to +151
// The crawl-info node can legitimately be empty for a short window: it happens when
// CoordinatorCleanupService is in the middle of deleting a finished crawl's ZK subtree
// at the same time this method reads it (checkExists() above succeeded, but the data was
// cleared/removed by the time we called getData()). This is expected, transient, and not
// an error worth a stack trace - see https://github.com/gbif/crawler/issues/2.
if (crawlJobBytes == null || crawlJobBytes.length == 0) {
LOG.warn(
"Crawl info node for dataset [{}] at path [{}] was empty, most likely a concurrent "
+ "cleanup deletion; treating this dataset as not currently being processed",
datasetKey,
crawlPath);
return null;
}
Wisienkas and others added 2 commits July 31, 2026 15:46
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
- Fixed other test not considering state of mocked service
- applied gbif style formatting
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