Make RedisInsight work with WithLifetime(...).

[mitchdenny]

Description

With this PR, when using WithRedisInsight(...) the list of databases will be fetched from the RedisInsight instance and where they overlap with the names of the Redis Instances running already it will delete them so that the subsequent import won't result in duplicated entries.

Fixes #6111

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue:
  • No

Microsoft Reviewers: Open in CodeFlow

[eerhardt]

Can you add some tests for this?

[mitchdenny]

@eerhardt working on it. Turns out we don't have any tests for WithLifetime(...) so I'm having to tackle a few first of a kind problems:

1. ResourceNameSuffix variations whilst under test.
2. Cleaning up "persistent" containers after the test.

[mitchdenny]

OK for the time being I've done a bit of a hack to make sure we have test coverage here. See the introduction of ApplicationExecutorProxy. Check out #6455 for more details on what I think the post 9.0 solution should look like.

NOTE: It was important to make sure we clean up these container that is running because due to persistence it would never have gotten cleaned up. So a dev running tests locally would just continue to accumulate Redis Insight instances - and if we did more persistent lifetime checks in CI we might end up running out of resources on the CI agent/Helix machines.

[eerhardt]

Why are we deleting the servers that are already there, only to add them again?

Wouldn't the more appropriate approach be "if the server already exists, don't add it again" ?

[mitchdenny]

Because the credentials could have changed. Using the api/databases call we don't have a mechanism to check that the credentials are the same, so we just blow it away and recreate.

[eerhardt]

It would be good to add this in a comment. I don't think this algorithm is intuitive.

[eerhardt]

It would be good to add this in a comment. I don't think this algorithm is intuitive.

Did this ever happen?

[eerhardt]

The change looks fine. I'd just add some comments on why we are doing it this way.

[mitchdenny]

/backport to release/9.0

[github-actions]

Started backporting to release/9.0: https://github.com/dotnet/aspire/actions/runs/11490840397