feat(analytics): support explicit count values in Count method

[wolf-06]

Description

Adds support for explicit count values in analytics.Count() by extracting int64 values from the last Properties argument when multiple are provided.

What's Changed

• Extract count from last Properties argument if multiple provided, summing all int64 values
• Fall back to count=1 when no explicit count is provided
• Add tests covering default, explicit, sum, and fallback behavior
• Update comment to explain the feature

Type of change

• New feature (non-breaking change which adds functionality)
• Test changes (add, refactor, improve or change a test)

---

FIXES #3382

[vercel]

@wolf-06 is attempting to deploy a commit to the Hatchet Team on Vercel.

A member of the Team first needs to authorize it.

[gregfurman]

Thanks for picking this up! I think the current approach needs some more consideration since (IMO) it's prone to incorrect usage and is not very self-documenting.

Wdyt of the approach outlined in #3382 that extends the analytics.Properties and uses a more explicit (and structured) typing system to determine values?

[gregfurman]

Tbh I still think we should be passing in a structured type to determine/override this value, where necessary instead of relying on a positional arg in the varadic params.

Like, it's more explicit that way i.e

a.Count(ctx, analytics.Log, analytics.Get, analytics.Properties{}, analytics.Increment(5))

versus:

a.Count(ctx, analytics.Log, analytics.Get, analytics.Properties{}, analytics.Properties{"": 5})

where the latter could be error prone as well since it means we'd need to document this positional behaviour.

This typed-approach also means we can extend supported operations i.e

a.Count(ctx, analytics.Log, analytics.Get, analytics.Properties{}, analytics.Decrement(5))
a.Count(ctx, analytics.Log, analytics.Get, analytics.Properties{}, analytics.Set(0)) // or maybe .Reset() ?

Then if we have other metric types (i.e a gauge or whatever) we can extend this approach to suit.

[wolf-06]

Fair enough,
will move with original approach of using structured property, which ig will also solve to other concerns automatically.

[gregfurman]

Unsure this is desirable due to the typing of analytics.Properties.

Like, analytics.Properties is a map[string]any which means (in the case of your changes) the last arg would still have to be correctly typed as such. So if I wanted to increment the count by 5 I'd need to pass a contrived map type where the keys will be ignored i.e

a.Count(ctx, analytics.Log, analytics.Get, analytics.Properties{},  analytics.Properties{"foo": 5}))

Also, if we pass in two (or more) properties, the caller has no way of knowing the final arg will have all of its values used for incrementing. This ambigious behaviour could lead to unintentionally passing props in that we expect to be included as tags/labels but get used to increment metrics.

[gregfurman]

This conversion means we're only ever supporting an int64 being explicitly passed in, meaning other numeric types being used would get skipped over.

i.e

a.Count(ctx, analytics.Log, analytics.Get, analytics.Properties{},  analytics.Properties{"foo": uint64(5)}))

Would see 1 being added since a uint64 is not an int64 -- hence it's skipped as type-checking fails.