query applicant by hbx id

[vkghub]

Reference ticket: https://app.clickup.com/t/868gvfe51

Summary by CodeRabbit

• Bug Fixes
  • Enhanced applicant subject matching in SSA VLP RJ3 processing with context-aware HBX ID lookup based on application type.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request refactors subject lookup logic in applicant request processing by replacing correlation_id/encrypted_ssn matching with hbx_id matching. A new private helper method applicant_hbx_id is introduced to compute the appropriate HBX ID based on FAA application context, and corresponding test setup is updated to populate hbx_id explicitly.

Changes

Cohort / File(s)	Summary
Subject lookup refactoring app/operations/fdsh/ssa_vlp/rj3/process_applicant_requests.rb	Replaces subject discovery from correlation_id/encrypted_ssn matching to hbx_id matching; adds applicant_hbx_id helper method that returns person_hbx_id for FAA context or hbx_id otherwise
Test data setup spec/operations/fdsh/ssa_vlp/rj3/process_applicant_requests_spec.rb	Updates test setup to explicitly populate hbx_id field using applicant_entity.person_hbx_id when creating transmittable_applicant

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• ssa vlp hub call #274: Modifies applicant identification logic by selecting between person_hbx_id and hbx_id for FAA vs non-FAA contexts, directly paralleling the applicant_hbx_id helper logic.
• adding vlp close case for applicants #273: Updates applicant processing to propagate and use applicants' hbx_id across request handling and event publishing, aligning with the hbx_id-focused changes here.
• vlp applicant request #268: Modifies the same class (ProcessApplicantRequests) for applicant request handling logic, creating direct code-level overlap.

Suggested labels

cr-120+

Suggested reviewers

• TristanB17
• jacobkagon

Poem

🐰 A helper born from FAA's gleam,
To match hbx_ids in applicant's dream,
No more correlation's winding way,
Just person_hbx_id saves the day! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: refactoring applicant lookup from correlation_id/encrypted_ssn matching to hbx_id-based querying via a new helper method.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @app/operations/fdsh/ssa_vlp/rj3/process_applicant_requests.rb:
- Line 38: The lookup in process_applicant_requests.rb now finds subject via
hbx_id (subject = @application.applicants.detect { |app| app.hbx_id ==
applicant_hbx_id }), but existing Applicant records may have nil hbx_id; add a
data-migration to backfill Applicant.hbx_id from existing correlation_id or
encrypted_ssn values before deploy, OR modify
fetch_subject/handle_verification_request to fallback when hbx_id is nil (e.g.,
if no match by hbx_id, attempt detect by correlation_id or encrypted_ssn) so
existing records are still resolved until the migration completes.

🧹 Nitpick comments (1)

spec/operations/fdsh/ssa_vlp/rj3/process_applicant_requests_spec.rb (1)

40-43: Test changes align correctly with FAA application logic, but consider adding non-FAA coverage.

The test setup correctly uses person_hbx_id from the applicant entity, matching the implementation's behavior for FAA applications. However, since non-FAA applications use @applicant_entity.hbx_id instead (see line 86 in the implementation), consider adding test coverage for non-FAA application scenarios to ensure both code paths work correctly.

📋 Suggested test for non-FAA applications

Add a context to test non-FAA applications:

context 'with non-FAA application' do
  let(:application_type) { 'non_faa' }
  
  before do
    # Update the setup to use hbx_id instead of person_hbx_id
    applicant = application.applicants.first
    applicant.update(hbx_id: applicant_entity.hbx_id)
  end

  it 'successfully finds subject using hbx_id for non-FAA applications' do
    result = subject.call(params)
    expect(result).to be_success
  end
end

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ccb3d81 and e87c500.

📒 Files selected for processing (2)

• app/operations/fdsh/ssa_vlp/rj3/process_applicant_requests.rb
• spec/operations/fdsh/ssa_vlp/rj3/process_applicant_requests_spec.rb

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-07-15T16:28:40.423Z

Learnt from: vkghub
Repo: ideacrew/fdsh_gateway PR: 268
File: app/operations/fdsh/ssa_vlp/rj3/vlp/process_verification_response.rb:119-123
Timestamp: 2025-07-15T16:28:40.423Z
Learning: In `app/operations/fdsh/ssa_vlp/rj3/vlp/process_verification_response.rb`, the application hash structure guarantees that top level keys like `:person_name` and `:demographics` will always be present, so direct hash access in `name_and_dob_match?` method is safe and doesn't require defensive navigation using `dig`.

Applied to files:

• spec/operations/fdsh/ssa_vlp/rj3/process_applicant_requests_spec.rb
• app/operations/fdsh/ssa_vlp/rj3/process_applicant_requests.rb

🧬 Code graph analysis (1)

app/operations/fdsh/ssa_vlp/rj3/process_applicant_requests.rb (2)

app/models/transaction.rb (1)

• applicants (54-56)

app/operations/fdsh/ssa_vlp/rj3/handle_verification_request.rb (1)

• faa_application? (190-192)

🔇 Additional comments (1)

app/operations/fdsh/ssa_vlp/rj3/process_applicant_requests.rb (1)

82-88: LGTM! Clean implementation following existing patterns.

The new applicant_hbx_id helper method correctly differentiates between FAA and non-FAA applications, following the same conditional pattern used by citizen_status and encrypted_ssn methods. The memoization is appropriate here.

[TristanB17]

lgtm

[jacobkagon]

Change LGTM!