Skip to content

feat: add new callback hook on_checkpoint_write_end #21323

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
wants to merge 6 commits into
base: master
Choose a base branch
from
Draft

feat: add new callback hook on_checkpoint_write_end #21323

wants to merge 6 commits into from
+92 −0

Conversation

@Iruos8805
Copy link

@Iruos8805 Iruos8805 commented Nov 2, 2025 •
edited by github-actions bot
Loading

What does this PR do?

This PR introduces a new callback hook, on_checkpoint_write_end, which is triggered after a checkpoint file has been fully written to disk.

It allows users to run custom logic such as validation, integrity checks, or post save actions once checkpoint writing is complete.

Currently, on_save_checkpoint is triggered before the checkpoint file is written to disk.
However, there is no callback hook that runs after the checkpoint write operation is fully complete.

This limitation makes it difficult to safely perform actions that depend on the finalized checkpoint file, such as:

  • Running integrity checks or file validations
  • Launching asynchronous or distributed processes that use the newly written checkpoint
  • Triggering external tools (uploading to remote storage, post-save logging)

The motivation behind this change is to enable developers to reliably run logic only after the checkpoint is guaranteed to exist on disk.

Fixes #15795

Before submitting
  • Was this discussed/agreed via a GitHub issue? (not for typos and docs)
  • Did you read the contributor guideline, Pull Request section?
  • Did you make sure your PR does only one thing, instead of bundling different changes together?
  • Did you make sure to update the documentation with your changes? (if necessary)
  • Did you write any new necessary tests? (not for typos and docs)
  • Did you verify new and existing tests pass locally with your changes?
  • Did you list all the breaking changes introduced by this pull request?
  • Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review

Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

Reviewer checklist
  • Is this pull request ready for review? (if not, please submit in draft mode)
  • Check that all items from Before submitting are resolved
  • Make sure the title is self-explanatory and the description concisely explains the PR
  • Add labels and milestones (and optionally projects) to the PR so it can be classified

📚 Documentation preview 📚: https://pytorch-lightning--21323.org.readthedocs.build/en/21323/

@github-actions github-actions bot added docs Documentation related pl Generic label for PyTorch Lightning package labels Nov 2, 2025
@bhimrazy
Copy link
Collaborator

bhimrazy commented Nov 4, 2025

Hi @Iruos8805,

I noticed there’s an after_save_checkpoint method defined in the logger:

pytorch-lightning/src/lightning/pytorch/loggers/logger.py

Lines 31 to 36 in 32442c2

class Logger(FabricLogger, ABC):
"""Base class for experiment loggers."""
def after_save_checkpoint(self, checkpoint_callback: ModelCheckpoint) -> None:
"""Called after model checkpoint callback saves a new checkpoint.

Would this method already address the issue being discussed here?

@Iruos8805
Copy link
Author

Iruos8805 commented Nov 5, 2025 •
edited
Loading

@bhimrazy

They serve different purposes according to my understanding.
after_save_checkpoint belongs to the logging subsystem and receives the ModelCheckpoint instance, not the Trainer, LightningModule, or the actual filepath. This means it can’t be used by user defined callbacks or modules to perform post save logic such as verifying, uploading, or cleanup.

on_checkpoint_write_end, on the other hand is a more general purpose hook and is available to all callbacks and LightningModules. It is invoked after the checkpoint file is physically written and all ranks synchronize, ensuring the file exists on disk. By providing the actual filepath, it enables users to perform actions like verification, uploading, or cleanup safely. This usability, I infer was what was suggested in the issue too. They are complementary rather than being redundant.

@bhimrazy bhimrazy marked this pull request as draft November 19, 2025 13:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@lantiga lantiga Awaiting requested review from lantiga lantiga is a code owner

@Borda Borda Awaiting requested review from Borda Borda is a code owner

@tchaton tchaton Awaiting requested review from tchaton tchaton is a code owner

@justusschock justusschock Awaiting requested review from justusschock justusschock is a code owner

@ethanwharris ethanwharris Awaiting requested review from ethanwharris ethanwharris is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

docs Documentation related has conflicts pl Generic label for PyTorch Lightning package

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

on_checkpoint_write_end callback

2 participants

@Iruos8805 @bhimrazy