You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GateIO: Update API fields due to widespread upgrade (thrasher-corp#2158)
* fix: update Gate.io websocket handling for size and amount conversions
- Added "X-Gate-Size-Decimal" header in the websocket connection for spot trading.
- Updated futures and options processing to convert sizes and amounts to float64 where necessary.
- Ensured consistency in handling size and amount across various functions in the Gate.io exchange wrapper.
* rm verbosity
* docs: Update type usage guidelines for API number handling due to benchmarks below
`types.Number` vs `float64` with `,string` — benchmark findings
Benchmarked at count=100 on AMD Ryzen 7 5800X (Windows, amd64):
| Field type | Avg ns/op | B/op | allocs/op |
|---|---|---|---|
| `float64` (bare number) | ~414 | 216 | 4 |
| `types.Number` (quoted string) | ~403 | 216 | 4 |
| `float64` + `,string` tag (quoted string) | ~506 | 264 | **7** |
`types.Number` is identical in cost to a bare `float64` — the custom `UnmarshalJSON` allocates nothing of its own (the compiler eliminates the `string(data)` conversion in `strconv.ParseFloat`). By contrast, `float64` with `,string` is ~25% slower and produces 3 extra allocations and 48 extra bytes per decode due to the stdlib reflection path it takes.
+**Calling `.Float64()` on a `types.Number` field is optional** — `types.Number` is defined as `type Number float64`, so a direct conversion `float64(n)` or storing it as `types.Number` and passing it where a `float64` is needed are both zero-cost. `.Float64()` is a convenience accessor and may be omitted when the call site already works with `types.Number` directly.
* glorious: don't send header down the spot connection, mv it to the futures connection
* crank/glorious: nits
* thrasher-:nits
* glorious: nits in your head
* Update exchanges/gateio/gateio_test.go
Co-authored-by: Adrian Gallagher <adrian.gallagher@thrasher.io>
* Update exchanges/gateio/gateio_test.go
Co-authored-by: Adrian Gallagher <adrian.gallagher@thrasher.io>
* Update exchanges/gateio/gateio_test.go
Co-authored-by: Adrian Gallagher <adrian.gallagher@thrasher.io>
* gate f usage
---------
Co-authored-by: Ryan O'Hara-Reid <ryan.oharareid@thrasher.io>
Co-authored-by: Adrian Gallagher <adrian.gallagher@thrasher.io>
Copy file name to clipboardExpand all lines: docs/CODING_GUIDELINES.md
+19-7Lines changed: 19 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,11 +22,9 @@ Refer to the [ADD_NEW_EXCHANGE.md](/docs/ADD_NEW_EXCHANGE.md) document for compr
22
22
### Type Usage
23
23
24
24
- Use the most appropriate native Go types for struct fields:
25
-
- If the API returns numbers as strings, use float64 with the `json:",string"` tag.
26
-
- For timestamps, use `time.Time` if Go's JSON unmarshalling supports the format directly.
27
-
- If native Go types are not supported directly, use the following built-in types:
28
-
-`types.Time` for Unix timestamps that require custom unmarshalling.
29
-
-`types.Number` for numerical float values where an exchange API may return either a `string` or `float64` value.
25
+
- If the API always returns a number as a bare JSON number, use `float64`.
26
+
- If the API returns a number as a quoted JSON string, or may return either a string or a bare number, use `types.Number` — **do not** use `float64` with the `json:",string"` tag.
27
+
- For timestamps, use `time.Time` if Go's JSON unmarshalling supports the format directly; otherwise use `types.Time` for Unix timestamps that require custom unmarshalling.
30
28
- Always use full and descriptive field names for clarity and consistency. Avoid short API-provided aliases unless compatibility requires it.
31
29
- Default to `uint64` for exchange API parameters and structs for integers where appropriate.
32
30
- Avoid `int` (size varies by architecture) or `int64` (allows negatives where they don't make sense).
@@ -112,13 +110,27 @@ Use `require` and `assert` appropriately:
112
110
113
111
- Use when test flow depends on the result.
114
112
- Messages must contain **"must"** (e.g., "response must not be nil").
115
-
- Use the *f* variants when using format specifiers (e.g., `require.Equalf`).
116
113
117
114
#### assert
118
115
119
116
- Use when the test can proceed regardless of the check.
120
117
- Messages must contain **"should"** (e.g., "status code should be 200").
@@ -2300,7 +2302,7 @@ func (e *Exchange) CancelMultipleFuturesOpenOrders(ctx context.Context, contract
2300
2302
// In the returned result, the succeeded field of type bool indicates whether the execution was successful or not
2301
2303
// If the execution is successful, the normal order content is included; if the execution fails, the label field is included to indicate the cause of the error
2302
2304
// In the rate limiting, each order is counted individually
0 commit comments