Skip to content

Stamp 1-based FLYTE_ATTEMPT env var alongside FLYTE_ATTEMPT_NUMBER - #7792

Draft
pvditt wants to merge 1 commit into
mainfrom
pvditt/attempt-1based-flyte-attempt-env
Draft

Stamp 1-based FLYTE_ATTEMPT env var alongside FLYTE_ATTEMPT_NUMBER#7792
pvditt wants to merge 1 commit into
mainfrom
pvditt/attempt-1based-flyte-attempt-env

Conversation

@pvditt

@pvditt pvditt commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Why are the changes needed?

Attempt numbering today is split across two conventions: the v2 wire/API (ActionAttemptIdentifier, console, action events) is 1-based, while the execution layer's TaskExecutionIdentifier.retry_attempt — and the FLYTE_ATTEMPT_NUMBER env var derived from it — is a 0-based retry index inherited from v1. User code inside a task therefore sees 0 for the same attempt the console displays as "Attempt 1".

This adds a 1-based FLYTE_ATTEMPT env var so SDKs can expose an attempt number consistent with the UI, without touching any existing consumer.

What changes were proposed in this pull request?

GetExecutionEnvVars stamps FLYTE_ATTEMPT (value RetryAttempt + 1) alongside the unchanged FLYTE_ATTEMPT_NUMBER. Purely additive: old SDKs keep reading the old var; new SDKs read FLYTE_ATTEMPT and fall back to FLYTE_ATTEMPT_NUMBER + 1 on backends without this change, so every old/new backend × old/new SDK combination behaves identically (companion SDK PR adds TaskContext.attempt with that fallback).

How was this patch tested?

Updated TestGetExecutionEnvVars and TestAddFlyteCustomizationsToContainer env-var count/index expectations; suite passes.

Labels

  • added

🤖 Generated with Claude Code

https://claude.ai/code/session_0199AnC2fWkbhANzJtAKEV61

GetExecutionEnvVars now additionally stamps FLYTE_ATTEMPT, the 1-based
attempt ordinal matching the wire/API convention (ActionAttemptIdentifier,
console). FLYTE_ATTEMPT_NUMBER (0-based retry index) is unchanged and kept
for existing SDK and user-code readers, so all combinations of old/new
backend and old/new SDK keep working: new SDKs fall back to
FLYTE_ATTEMPT_NUMBER + 1 when FLYTE_ATTEMPT is absent.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0199AnC2fWkbhANzJtAKEV61
Signed-off-by: Paul Dittamo <pvdittamo@gmail.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new 1-based attempt ordinal environment variable (FLYTE_ATTEMPT) to task pods so SDK/user code can read an attempt number consistent with the Flyte UI/wire conventions, while preserving the existing 0-based FLYTE_ATTEMPT_NUMBER for backward compatibility.

Changes:

  • Stamp FLYTE_ATTEMPT = RetryAttempt + 1 alongside the existing FLYTE_ATTEMPT_NUMBER.
  • Update unit tests to account for the additional env var (counts/indices).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
flyteplugins/go/tasks/pluginmachinery/flytek8s/k8s_resource_adds.go Adds the new FLYTE_ATTEMPT env var derived from RetryAttempt + 1.
flyteplugins/go/tasks/pluginmachinery/flytek8s/k8s_resource_adds_test.go Updates expectations for env var list size / placement in GetExecutionEnvVars tests.
flyteplugins/go/tasks/pluginmachinery/flytek8s/container_helper_test.go Updates container env-var count expectation due to the added env var.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

// (ActionAttemptIdentifier, console). FLYTE_ATTEMPT_NUMBER above is the
// 0-based retry index and is kept for existing SDK/user-code readers.
Name: "FLYTE_ATTEMPT",
Value: strconv.Itoa(int(id.GetID().RetryAttempt) + 1),
Comment on lines 63 to 67
envVars := GetExecutionEnvVars(mock, tt.consoleURL)
assert.Len(t, envVars, tt.expectedEnvVars)
if tt.expectedEnvVar != nil {
assert.Equal(t, tt.expectedEnvVar, &envVars[5])
assert.Equal(t, tt.expectedEnvVar, &envVars[6])
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants