fix(integrations): fall back when shipping is blank [INT-36]

[mikeh-lago]

⚠️ Local validation incomplete (Mode B): the runner has no Postgres/Redis/ClickHouse available, so RSpec was not run locally. Rubocop was run on all 10 changed files and is green. Validation delegated to CI — please wait for CI to be green before reviewing.

Summary

Customers created via the UI without a shipping address persist empty strings (rather than NULL) in shipping_* columns. The Anrok and Avalara tax-integration payloads fell back from customer.shipping_* to billing customer.address_* using bare ||, which does not catch "" in Ruby — so the integrations were receiving empty addresses and failing.

Fix: switch the fallback from || to .presence || in the Anrok and Avalara payload builders. "".presence is nil, so the fallback chain now does what it was always meant to do.

Files touched

Production:

• app/services/integrations/aggregator/taxes/invoices/payloads/anrok.rb
• app/services/integrations/aggregator/taxes/invoices/payloads/avalara.rb
• app/services/integrations/aggregator/taxes/credit_notes/payloads/anrok.rb
• app/services/integrations/aggregator/taxes/credit_notes/payloads/avalara.rb
• app/services/integrations/aggregator/contacts/payloads/avalara.rb (Avalara contacts is part of the same tax flow)

Tests: matching describe "shipping address fallback" block added to each of the 5 specs, asserting empty-string → fallback, nil → fallback, and non-empty shipping preserved.

What was NOT done and why

• No data migration on customers. The Linear description proposed a raw UPDATE customers SET shipping_* = NULLIF(...). Per @yohan's 2026-05-11 comment on INT-36, "a data migration here is unnecessary. We should update the integration code with customer.shipping_address_line1.presence || customer.address_line1." That is the direction implemented here. If a backfill is later judged necessary (it likely isn't, since the integration code now handles "" correctly), it should be done as a batched migration job in app/jobs/database_migrations/ per Julien's earlier comment — not as a single unbatched UPDATE on the customers hot table.
• NetSuite contacts payload was not touched. Contacts::Payloads::Netsuite uses customer.shipping_address_line1&.first(N) and does not have a fallback-to-billing pattern. It is not a tax integration and is outside this ticket's scope (the ticket explicitly says "issues with our tax integrations"). If NetSuite needs similar handling, that is a separate ticket.
• No frontend change. Stopping the UI from persisting "" in the first place is a sensible follow-up but is outside this ticket and a different team (Front).

Performance notes

This is a pure expression-level change in payload builders that are already called once per integration request. Adding .presence is O(1) per field. No new DB queries, no allocations in a loop, no hot-path impact. Section 4 bis questions all answered "no concern."

How a reviewer can verify locally

bundle exec rspec spec/services/integrations/aggregator/taxes/invoices/payloads/anrok_spec.rb \
                  spec/services/integrations/aggregator/taxes/invoices/payloads/avalara_spec.rb \
                  spec/services/integrations/aggregator/taxes/credit_notes/payloads/anrok_spec.rb \
                  spec/services/integrations/aggregator/taxes/credit_notes/payloads/avalara_spec.rb \
                  spec/services/integrations/aggregator/contacts/payloads/avalara_spec.rb
bundle exec rubocop app/services/integrations/aggregator/{taxes,contacts}/

Linear

INT-36 — Data Migration, "" in shipping address issue

---

🤖 Generated by the ai-augmented pilot (Claude Code, Opus 4.7). Direction sourced from @yohan's 2026-05-11 comment on INT-36.

[ancorcruz]

LGTM.

We could DRY this pattern up across 5 payload builders exposing a #effective_shipping_address helper in Customer model that does the .presence || fallback.

Do you think it would make sense in the Customer create/update services cleaning the attributes to ensure no "" is saved for new customers or updates?