Skip to content

Split StatusSchema and RangeLock from ManagementAPI#13380

Open
tclinkenbeard-oai wants to merge 1 commit into
apple:mainfrom
tclinkenbeard-oai:dev/tclinkenbeard/split-management-api-status-rangelock
Open

Split StatusSchema and RangeLock from ManagementAPI#13380
tclinkenbeard-oai wants to merge 1 commit into
apple:mainfrom
tclinkenbeard-oai:dev/tclinkenbeard/split-management-api-status-rangelock

Conversation

@tclinkenbeard-oai

Copy link
Copy Markdown
Collaborator

This PR is a straightforward refactoring to shrink the size of ManagementAPI.cpp, which often takes a long time to compile. StatusSchema and RangeLock implementations are moved to separate files.

@tclinkenbeard-oai tclinkenbeard-oai left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Generated by Codex.

What is it trying to do?

Split the RangeLock and StatusSchema implementations and declarations out of ManagementAPI.cpp/.h into focused files, reducing ManagementAPI.cpp compile cost and replacing transitive includes with explicit owning headers.

Is it correct?

Yes, based on code inspection. The moved RangeLock and StatusSchema function bodies match the originals aside from making previously file-local helpers anonymous-namespace symbols. The declarations keep the same signatures, all in-tree callers include the new headers, and fdb_find_sources picks up both new .cpp files.

No serialized fields, durable formats, protocol boundaries, status output, hot-path algorithms, async behavior, assertions, trace events, or simulation hooks changed.

I did not run builds or tests. Public CI currently has clang-format passing; the Windows Boost check, FoundationDB builders, and Cluster Tests are still pending, with no reported failures.

Are there bugs?

I did not find any correctness bugs.

Are there omissions?

None that I think block this. No new behavioral tests are needed for a body-preserving extraction; the remaining risk is platform-specific compile/link integration, which pending CI should cover.

Are there better ways of doing things?

No material alternative. Moving the declarations to the owning headers and updating consumers to include those headers directly is the appropriate split.

Should this CL be LGTMd?

Yes, LGTM from code inspection. I would still wait for the pending CI checks before merging.

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-clang-ide on Linux RHEL 9

  • Commit ID: 8d18f51
  • Duration 0:20:39
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-macos-m1 on macOS 14.x

  • Commit ID: 8d18f51
  • Duration 0:34:57
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-clang-arm on Linux RHEL 9

  • Commit ID: 8d18f51
  • Duration 0:45:39
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-clang on Linux RHEL 9

  • Commit ID: 8d18f51
  • Duration 0:50:48
  • Result: ❌ FAILED
  • Error: Error while executing command: python3 -m joshua.joshua start --tarball $(find build_output/packages -name correctness\*.tar.gz) --username ${CORRECTNESS_USERNAME} --max-runs 10000. Reason: exit status 1
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr on Linux RHEL 9

  • Commit ID: 8d18f51
  • Duration 0:53:51
  • Result: ❌ FAILED
  • Error: Error while executing command: python3 -m joshua.joshua start --tarball $(find build_output/packages -name correctness\*.tar.gz) --username ${CORRECTNESS_USERNAME} --max-runs 10000. Reason: exit status 1
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-cluster-tests on Linux RHEL 9

  • Commit ID: 8d18f51
  • Duration 1:01:17
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)
  • Cluster Test Logs zip file of the test logs (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-macos on macOS 14.x

  • Commit ID: 8d18f51
  • Duration 1:04:03
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-clang on Linux RHEL 9

  • Commit ID: 8d18f51
  • Duration 1:00:41
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr on Linux RHEL 9

  • Commit ID: 8d18f51
  • Duration 1:01:15
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

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.

2 participants