Migration to uint64

[Vedant-03]

The current implementation uses uint32 in most places to represent the traded volume for an instrument.

While this is sufficient under normal market conditions, it introduces the possibility of integer overflow if the traded volume exceeds 4,294,967,295 (math.MaxUint32). Although this may be uncommon today, it is a hard limit that could be reached during periods of exceptionally high trading activity or as market volumes continue to grow over time.

I came across an older forum discussion that raises the same concern: ref

It may be worth considering changing the volume type to uint64 (or another larger integer type) throughout the codebase to eliminate this limitation and make the implementation more future-proof.

[UjjwalGupta49]

Summary

The overflow concern is valid, but the hard limit is not primarily caused by the type of models.Tick.VolumeTraded. For WebSocket ticks, the limit comes from the binary protocol itself: the server sends volume in a fixed four-byte field.

Changing the exported Go field from uint32 to uint64 would widen the destination after those four bytes have already been decoded. It would not recover or represent any value above math.MaxUint32.

Where the limit exists

The ticker protocol currently defines fixed packet sizes:

• quote packet: 44 bytes
• full packet: 184 bytes

These sizes are encoded in ticker/ticker.go.

For a tradeable quote, the parser reads volume from bytes 16:20:

VolumeTraded: binary.BigEndian.Uint32(b[16:20]),

See ticker/ticker.go#L703-L720.

The public model then stores that decoded value as uint32 in models/snaps.go#L25-L45.

This matches the current Kite WebSocket packet specification, where:

• volume occupies bytes 16-20;
• total buy quantity starts immediately at bytes 20-24;
• total sell quantity occupies bytes 24-28;
• the remaining OHLC, timestamp, OI, and depth fields have fixed offsets.

The older forum example involved a value of 2,419,188,400. That exceeds signed int32, but it is still below math.MaxUint32 (4,294,967,295). The existing Go client already decodes it with binary.BigEndian.Uint32, so that particular signed-overflow case is handled by the current implementation.

Why changing to uint64 does not fix the root cause

A client-only change such as:

VolumeTraded uint64

would still decode the same four source bytes. At most, it would zero-extend a uint32 value into a uint64 destination.

If the real volume exceeds math.MaxUint32, the current packet cannot carry the value. The value must already have been truncated, wrapped, saturated, or otherwise transformed before the Go client receives it. No destination type can reconstruct those lost upper bits.

Changing only the model would therefore change the API surface without changing the protocol limit. It would also be source-breaking for consumers using typed assignments, struct literals, comparisons, or function arguments involving uint32.

A blanket uint32 to uint64 migration would additionally conflate unrelated fields. Instrument tokens, quantities, OI fields, and depth values have their own protocol widths and should not be migrated solely because traded volume may eventually outgrow four bytes.

REST and WebSocket values should be treated separately

The REST quote path is not constrained by the WebSocket packet layout. It currently uses Go int fields for volume and related quantities in market.go#L18-L36, even though the REST market quote documentation describes these quantities as int64.

The same platform-sized int pattern appears in:

• historical volume and OI;
• alert history quantities.

Aligning these JSON-backed fields to int64 is reasonable, but it is a separate contract-alignment change and should not be presented as a fix for the four-byte WebSocket field.

Recommended resolution

The complete fix requires the protocol and client to evolve together:

1. Define a new server-side WebSocket packet format in which volume occupies eight bytes.
2. Version or otherwise distinguish the new packet layout so existing 44-byte and 184-byte packets remain decodable.
3. Update all offsets following the volume field according to that specification.
4. Add dual-format decoding to the client: preserve the existing packet paths and add an explicit branch for the new packet lengths.
5. Expose the widened WebSocket volume as uint64 in a major release because changing the exported field type is source-breaking.
6. Test both legacy and new packets, including math.MaxUint32, math.MaxUint32 + 1, and every field whose offset follows volume.
7. Handle REST quantity alignment independently by moving documented JSON int64 fields away from platform-sized int, also as part of an announced breaking release.

Until the server protocol defines an eight-byte field, the client should document the current unsigned 32-bit ceiling rather than imply that a model-only migration removes it.

Smallest pattern-aligned change for the current codebase

For v4 and the current wire protocol, the narrowest change is:

• keep Tick.VolumeTraded and the existing packet decoder as uint32;
• add a boundary case to the existing table-driven parser test in ticker/ticker_test.go that writes 0xffffffff to bytes 16:20 and asserts VolumeTraded == math.MaxUint32;
• document that WebSocket traded volume is limited by the current four-byte wire field;
• track REST int64 alignment and any future WebSocket protocol revision as separate changes.

This follows the repository's existing fixed-length parsing and table-driven test patterns, avoids a broad type migration that cannot solve the wire-level limitation, and leaves a clear upgrade path once the server supplies the additional bits.