[Tests] Run the skipped blob read/summarize tests by recruiting blob workers

Open
  • Is something wrong?
#175 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
docker-compose, php, testing-qa
Domain
databases, testing

Research direction

Start with tests/Integration/BlobGranuleTest.php:208-272 and docs/blob-granules.md:172-180, then inspect the compose stack and CI setup to see how blob workers can be recruited. Check the FoundationDB 7.3 blob-granule process requirements before choosing a worker-capable stack or profile. Done means both success paths run with meaningful read, loader callback, and summary assertions, the documented skip count drops to four, and make test-integration and ci-ok pass.

Written by the indexing model from the issue text.

Description

priority:low type:tests

Description

tests/Integration/BlobGranuleTest.php:208-249 (readBlobGranulesIssuesRequest) and :252-272 (summarizeBlobGranulesReturnsSummaries) still markTestSkipped() on the compose stack because the five-process cluster runs a blob manager but recruits no blob workers / has no granule history. docs/blob-granules.md:172-180 documents the two skips; the healthcheck added in #160 / PR #170 proves only that the blob manager is alive, not that granules can be read or summarized.

Impact: the blob read and summarize success paths are not exercised end-to-end. The tests pass as long as the expected exceptions are thrown, and when they do run they are weak: readBlobGranulesIssuesRequest asserts count($kvs) >= 0 (always true), defines a loader but never passes it, and calls readBlobGranules(..., loader: null, ..., debugNoMaterialize: true), so the loader callbacks are not exercised; summarizeBlobGranulesReturnsSummaries has no assertNotEmpty($summaries), so an empty result passes. A regression in the success path would not be caught. The suite reports 6 skips (4 from AdminDestructiveOperationsTest, 2 from this class).

Where to start

  • Add a process that can host a blob worker role to the compose stack (for example a dedicated fdbserver with the blob-worker process class, or a separate opt-in profile/stack), with the same fdb-blobs volume and bg_url knob. Check the FDB 7.3 blob-granule documentation for the process class/recruitment requirement.
  • Alternatively, provide a separate opt-in profile for the worker-capable tests and run it in CI, keeping the default five-process stack small.
  • Once workers are present, assert the happy path: a non-empty readBlobGranules() result with a loader that records calls, and non-empty summaries; keep a skip only for clusters without a blob store.
  • Update docs/blob-granules.md and the expected skip count when the tests run.

Definition of done

  • readBlobGranulesIssuesRequest and summarizeBlobGranulesReturnsSummaries execute their success path on the documented test stack (or an opt-in CI profile).
  • The success-path assertions are meaningful (non-empty result/summaries, loader callbacks observed).
  • The suite skip count drops from 6 to 4 on that stack; the remaining skips are still documented.
  • docs/blob-granules.md matches the run/skip behaviour.
  • make test-integration and ci-ok are green.
Dominant language
PHP
Stars
0
Forks
0
Avg merge
10h 4m
Merged PRs (30d)
19

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from crazy-goat/fdb-php

All issues in crazy-goat/fdb-php

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.