Add IsEphemeral() property to Partition interface

[rkannan82]

What

Add IsEphemeral() method to the Partition interface and replace Kind() == STICKY checks where the behavior applies to all ephemeral partition types, not just sticky queues.

Why

Several Kind() == STICKY checks in the matching service guard behaviors that apply to any ephemeral/transient partition (TTL-based expiry, no fairness, no versioning, no multi-partition fan-out, no enhanced describe). Extracting this into a property method makes it easy to add new ephemeral partition types (e.g. worker-commands) without auditing every check. Sticky-specific checks (stickiness clearing, deployment pinning, versioning in Poll) are left unchanged.

How did you test it?

Unit tests (go test ./service/matching/...) and full repo build (go build ./...). No behavioral changes — pure refactor replacing type checks with a semantic property.

🤖 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