Skip to content

Normalize OCC option symbols from broker sync to compact format#738

Open
triantos wants to merge 2 commits intoafadil:mainfrom
triantos:fix/connect-option-symbol-spaces
Open

Normalize OCC option symbols from broker sync to compact format#738
triantos wants to merge 2 commits intoafadil:mainfrom
triantos:fix/connect-option-symbol-spaces

Conversation

@triantos
Copy link
Contributor

Summary

  • Brokers (via SnapTrade) may return space-padded OCC symbols (e.g. GE 270115C00340000) which creates duplicate assets when the same contract also appears in compact form (GE270115C00340000)
  • Parse incoming option symbols in the broker mapping layer with the existing parse_occ_symbol() utility and rebuild in compact format via build_occ_symbol() to ensure consistent asset identity

Test plan

  • Verify existing option positions from Connect sync are not duplicated
  • Verify option symbols from non-Connect sources (CSV import, manual entry) are unaffected
  • All existing tests pass

Strip the weight suffix from metal instrument symbols before passing
them to price providers. XAU-500G and XAU-1KG were being sent as-is,
causing both Yahoo and Metal Price API lookups to fail with "no
providers available". The weight conversion is already handled
separately by metal_weight_oz().
@afadil
Copy link
Owner

afadil commented Mar 18, 2026

[P2] Option symbol normalization is already handled downstream

This looks redundant now.
Option symbol normalization is already happening in the current sync path: option positions are normalized in broker sync, and activity symbols are normalized again when prepare_activities_for_sync() builds the asset spec. That means asset identity is already canonicalized before instrument_key generation, so doing another normalization here does not fix a missing case in the final path.

If we keep any normalization at this layer, it should call the shared normalize_option_symbol() helper rather than duplicating parse/rebuild logic, otherwise this can drift from the canonical path and miss broker-specific compact formats.



**[P1] Metal weight is dropped during pricing
I don’t think the metal change is safe to merge as written.**



Normalizing XAU-500G / XAU-1KG to XAU fixes provider lookup, but it also changes the pricing unit to a 1 oz spot quote. The valuation path still uses quantity * price * contract_multiplier, and contract_multiplier() is 1 for metals, so metal_weight_oz() is never applied anywhere. As a result, one XAU-500G holding would now be valued as one ounce of gold instead of ~16.0754 oz.

So I agree with normalizing for provider lookup, but we also need a weight-aware adjustment before merging this, for example by scaling latest/historical metal quotes by metal_weight_oz() (or otherwise carrying the weight through valuation).

contract_multiplier() now returns metal_weight_oz() for precious
metals, so that weight-suffixed symbols like XAU-500G (16.075 oz)
and XAU-1KG (32.151 oz) are valued correctly when priced against
a per-troy-oz spot quote. Previously metal_weight_oz() existed but
was never called in any valuation path.
@triantos triantos force-pushed the fix/connect-option-symbol-spaces branch from 4d9b476 to 89de31b Compare March 18, 2026 20:52
@triantos
Copy link
Contributor Author

Re option normalization: OK, yes this is no longer needed now that you've merged my other change and normalize_option_symbol().

On the topic of metals, this got lost during one of my refactors. Sorry. I have fixed with an updated [trivial] commit.

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