Skip to content

docs: 7421 client-processing-documentation - #6549

Open
ttoomey wants to merge 1 commit into
mainfrom
7421-client-processing-documentation
Open

docs: 7421 client-processing-documentation#6549
ttoomey wants to merge 1 commit into
mainfrom
7421-client-processing-documentation

Conversation

@ttoomey

@ttoomey ttoomey commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Merging this PR

  • use the squash-merge strategy for PRs targeting a release-X branch

Description

Address documentation gaps around client processing. See issue description for details

Type of change

Documentation

Checklist before requesting review

  • I have performed a self-review of my code

@ttoomey
ttoomey requested review from eanders and gigxz June 3, 2026 15:49
Comment on lines +120 to 131

The callbacks use `after_save` rather than `after_commit` deliberately: `after_save` gives reliable access to `saved_changes` within a transaction, at the cost of occasionally queuing a redundant rebuild if the transaction is later rolled back. The queue is de-duplicated so rapid edits do not pile up jobs. Shared queuing logic lives in `Hmis::Hud::Concerns::ServiceHistoryQueuer` (`drivers/hmis/app/models/hmis/hud/concerns/service_history_queuer.rb`).

### Manual Rebuild Process

The steps below are required in two situations: targeted developer intervention, and **any console-level data fix**. When records are corrected directly via `update_columns`, `update_all`, raw SQL, or bulk import, the model callbacks do not fire — neither the processed-state clear nor the job enqueue happens automatically. The operator must perform both steps explicitly.

To manually trigger a service history rebuild for specific enrollments:

```ruby
# Invalidate enrollment(s) - this clears the processed_as hash
enrollment.invalidate_source_data!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

In HMIS code (and adhoc developer action), we run invalidate_processing! on the enrollment or set of enrollments. The logic is:

def self.invalidate_processing!
update_all(processed_as: nil, processed_hash: nil)
end
def invalidate_processing!
# use update_columns to avoid stale object errors when this method is called from Service after_commit hooks
self.class.without_optimistic_locking do
update_columns(processed_as: nil, processed_hash: nil)
end
end

It seems like the difference is:

  • invalidate_processing! clears both processed_as and processed_hash on the specified enrollment(s)
  • invalidate_source_data! clears processed_as on the enrollment AND on any household member's enrollments

So I have a couple questions:

  • Is it safe to say it is the callers responsibility to ensure that ALL household enrollments are invalidated when necessary (i.e. by using invalidate_source_data! or invoking invalidate_processing! for each member)? (There is no built-in logic to Service History Enrollment processing to ensure that all household members are reprocessed when one is invalidated?)
  • What is the significance of clearing processed_hash vs not clearing it?

@gigxz gigxz Jun 4, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Depending on the answers to those questions, probably worth adding something here about significance of reprocessing a whole household together.

I think an example is: one Enrollment in the household is deleted, leading to the household composition to change from 'adults with children' to 'adults only' (not exact terms, but we have something like that on SHE). In addition to the newly deleted Enrollment being reprocessed, all remaining Enrollments must also be reprocessed in order to reflect the updated composition of the household for those enrollments.

@gigxz gigxz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

great additions and clarifications, thank you!

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