Summary
The user is experimenting with Flyte and has observed that while node IDs typically follow a pattern, a second nested node has a random string as its ID. They are curious about the logic behind this ID generation process. The user notes that for workflows with over 20 nodes, Flyte uses a hash for node IDs to reduce pressure on etcd capacity, where execution status is stored. They recognize that this behavior is by design and not configurable. The user thanks others for their insights and speculates that the random ID may be due to nested conditions in their workflow, which has fewer than 10 nodes. Another user corrects them, stating that the transition to hashed IDs is based on the length of the node ID in characters, not the number of nodes.