Add fine-grained partition properties to replace Kind() checks

[rkannan82]

What

Add property methods to the Partition interface — PersistenceTTL(), SupportsFairness(), SupportsVersioning(), SupportsPartitions() — and use them in place of Kind() == STICKY checks where the behavior isn't sticky-specific.

Describe task queue checks use Kind() == NORMAL since only user-facing queues can be described.

Why

Kind() == STICKY checks conflated multiple independent concerns. Fine-grained properties make each check self-documenting and make it easier to set correct values for new partition types.

How did you test it?

Unit tests (go test ./service/matching/... ./common/tqid/...). No behavioral changes — pure refactor.

🤖 Generated with Claude Code

[dnr]

Several Kind() == STICKY checks in the matching service guard behaviors that apply to any ephemeral/transient partition

I think I'd like to split this up further:

TTL-based expiry

The goal is we want to use metadata TTLs for any queue that has the property: if the queue is idle (no poller or tasks) for 48 hours, it's okay to drop all tasks in it. Sticky fits that description, as do worker command queues. I think basically any worker-specific task queue would, right?

no fairness

This one feels a little different.. for more "scheduling"/"placement" approaches to matching where we send a high volume of tasks over a worker-specific channel, we may definitely want fairness there even though it's a worker-specific queue. (The problem with fairness + TTLs is for tasks, it doesn't apply to metadata. Though yeah, maybe it's silly to TTL metadata without TTLs on tasks. We'd eventually want a scavenger.)

no versioning

I'm not sure here, I guess by definition worker-specific doesn't need versioning. But maybe some other kind of "ephemeral" queues could be versioned?

no multi-partition fan-out

Also potentially different.. in theory we could have a high volume worker-specific queue accepting/dispatching tasks enough that want to spread them over a few partitions. After dynamic partition scaling maybe we should relax this for all queues, including sticky, and just default to 1 but let them scale?

no enhanced describe

I think this mostly has to do with versioning?

More behavior differences:

Sticky queues get userdata (and thus config) from a normal "parent". Should other ephemeral queues do that too?

"Return error on Add*Task if no poller in last 10s". That could apply to worker commands, maybe with a different timeout though? 5m?

Priority backlog forwarding: this is tied to having a normal "parent" partition(s), should probably match that.

Migration to v2 table: this is tied to fairness. Can be relaxed eventually.

So we could have (hand-waving draft):

SupportsFairness() bool
SupportsPartitions() bool
SupportsVersioning() bool
NormalParent() (string, bool)
RejectTaskIfNoPollerInterval() time.Duration // 0 means never reject
DeleteIfIdleTimeout() time.Duration // 0 means never
OverrideNameInMetrics() string // "" means use name as-is

[dnr]

Oh, and the original one that started this:

Appears in metric labels

[dnr]

looks good, with one tweak

[ShahabT]

lgtm otherwise