cloudbyIndex approach to handle clouds with same name is broken

[mawinter69]

Jenkins and plugins versions report

Environment

Jenkins 2.547

Any of the cloud plugins that allow to to create clouds with same name, e.g. google-compute-engine or j

clouds

What Operating System are you using (both controller, and any agents involved in the problem)?

not relevant

Reproduction steps

1. create 3 clouds with the same name but configure one field to be different on each cloud (e.g. project id in gce)
2. open the configure page for cloud with index 2
3. delete the first cloud
4. change the instancecap of cloud 2 and save the cloud
5. check the clouds project ids

Expected Results

clouds have different project id

Actual Results

clouds have same project id
but different instance caps

Anything else?

The problem is that when the first cloud is deleted the index of the other 2 clouds changes.
So while saving cloud 2 one actually modifies cloud 3.

Are you interested in contributing a fix?

No response

[mawinter69]

The problem also exists when only 2 clouds with same name exist and there is a third cloud with a different name that has a lower index than the others.

[Raghav1428]

Hi! I’m interested in contributing a fix for this issue.

From what I’ve observed, the root cause appears to be that the cloud update logic relies on the index of the cloud in the list. When a cloud with the same name is deleted, its removal shifts the indices of the remaining clouds, causing updates to target the wrong entry.

My planned approach is to modify the cloud config handling so that each cloud uses a stable unique identifier (rather than the list index) for selection and updates. This will prevent index shifts from affecting which cloud is being modified.

I’ll start by identifying how clouds are currently serialized and updated in the core, adding unique IDs where necessary, and updating the UI to pass those IDs on save. If there are any suggestions or preferences for implementation details (e.g., naming conventions or existing helpers), I’d love to hear them.

Thanks!

[Raghav1428]

I was able to reproduce this on Jenkins 2.548 by creating multiple distinct Cloud objects with the same name (via Script Console, since the UI now prevents duplicate names).

After deleting the first cloud and editing one of the remaining clouds, both remaining clouds were updated to the same value. This confirms the bug is still present and that cloud updates are applied based on list position rather than a stable identifier, and in some cases affect multiple entries.

So the issue is not just historical — the core behavior is still broken when duplicate cloud names exist.

[Raghav1428]

Hi @mawinter69,

I've been investigating this bug and I think the root cause is pretty clear - using indexOf() for URL routing is fragile. I'd like to propose switching to unique IDs instead. Here's my plan, would appreciate your feedback before I start coding.

Summary

The fix introduces a uniqueId field to the Cloud class, which provides stable identification even when clouds are added, removed, or reordered. The change is backward-compatible with existing configurations.

Key Changes

1. Add uniqueId field to Cloud.java

   • Auto-generated UUID on creation
   • Uses readResolve() to migrate existing clouds without IDs on load
   • Thread-safe with double-checked locking

2. Update URL routing in CloudSet.java

   • Change from /cloud/cloudByIndex/{index}/ to /cloud/cloudById/{uniqueId}/
   • Keep getCloudByIndex() deprecated but functional for backward compatibility

3. Add lookup methods

   • Jenkins.getCloudById(String id) - top-level lookup
   • CloudList.getById(String id) - collection-level lookup
   • Both include null/empty string validation

4. Update doConfigSubmit() in Cloud.java

   • Use ID-based lookup first, fall back to name-based for compatibility
   • Preserve unique ID through reconfiguration

Backward Compatibility

• Existing configurations: Automatically get IDs assigned via readResolve() when loaded
• Old URLs: Index-based URLs continue to work (deprecated)
• No breaking changes: Only additive changes to the API

The Problem

The issue is in CloudSet.java - it uses getClouds().indexOf(cloud) to generate URLs when there are duplicate cloud names. When you delete a cloud, all the indices shift, but any open browser tabs still reference the old indices. That's why you end up editing the wrong cloud.

Testing Strategy

I've prepared comprehensive tests including:

• Unique ID generation and persistence
• The core bug scenario (duplicate name cloud deletion)
• Thread safety for concurrent ID access
• UUID collision prevention (1000 clouds test)
• Null/empty validation
• Configuration reconfiguration ID preservation
• Backward compatibility with configurations lacking IDs

Quick Questions Before I Start

1. UUID Format: I'm planning to use full UUIDs (36 chars). Should I shorten them to something like 16 chars for cleaner URLs?

2. Performance: The getCloudById() lookup is O(n). Given typical cloud counts, is linear search fine or should I optimize with a Map?

3. Migration: I'm handling it automatically via readResolve(). Do you want an admin command too, or is auto-migration enough?

Let me know your thoughts and I'll get started. Happy to clarify anything or work on improvements if needed.

[timja]

Approach sounds sensible.

Would appreciate trimming back the AI response and just including the key points.

I don't need to read the AI ramble and the key points you can decide on.

[Raghav1428]

Thank you for the feedback!

Key points:

1. Add uniqueId field instead of index and update the url respectively.
2. Use readResolve for migration

Please could you help me with the queries i have regrading the solution:

1. Shall i use UUID(32 chars)?

And sorry for the AI thing I have just begun my open source journey, and I am just new to these things and have no idea about how to submit the approach I am planning on using so, I took help from Claude to draft my message from the next time I will draft it myself and clarify over the conversation.

Thanks!

[timja]

UUID should be fine

[Raghav1428]

Sure, i will start working on it