crossplane/crossplane

E2E tests don't validate realtime composition performance for namespaced XRs

Aberta

#6.788 aberto em 8 de set. de 2025

 (9 comentários) (0 reação) (0 responsável)Go (1.211 forks)auto 404
compositionenhancementgood first issuehelp wantedtest

Métricas do repositório

Stars
 (11.845 estrelas)
Métricas de merge de PR
 (Métricas PR pendentes)

Description

What problem are you facing?

Our E2E test suite doesn't catch performance regressions in realtime composition for namespaced XRs. This was highlighted by https://github.com/crossplane/crossplane/pull/6780, which fixes a bug where realtime composition was broken for namespaced XRs - causing them to fall back to polling with ~1 minute delays instead of immediate updates.

The existing E2E tests validate functional correctness (does composition work?) but not performance characteristics (how fast does realtime composition respond?). Specifically:

  1. TestCompositionRevisionSelection tests realtime behavior but uses cluster-scoped XRs, not namespaced ones
  2. TestBasicCompositionNamespaced uses namespaced XRs but doesn't test realtime updates to composed resources
  3. Test timeouts are generous enough (10+ seconds) that they would pass even with the ~60 second polling fallback

The bug in #6780 affected the indexing and enqueueing logic specifically for namespaced XRs:

  • Resource references from namespaced XRs were indexed with empty namespaces
  • Composed resource changes were looked up using their actual namespace
  • The mismatch broke realtime updates, causing fallback to polling

How could Crossplane help solve your problem?

We need an E2E test that validates realtime composition performance for namespaced XRs. The test should:

  1. Create a namespaced XR that composes resources (e.g., ConfigMaps)
  2. Wait for initial composition to complete
  3. Directly modify a composed resource (e.g., add a label or annotation)
  4. Verify the XR status reflects the change within a tight timeout (2-3 seconds)
  5. Use tight timeouts to distinguish between realtime updates and polling fallback

This would catch indexing/enqueueing bugs because:

  • Without proper realtime composition: XR update takes ~60 seconds (polling interval)
  • With working realtime composition: XR update happens within seconds

The test should be similar to the existing TestCompositionRevisionSelection but specifically for namespaced XRs and focused on composed resource change detection rather than composition revision changes.

This would prevent regressions like #6780 from going unnoticed and ensure realtime composition performance is maintained for both cluster-scoped and namespaced XRs.

Guia do colaborador