feat: store credential expiration epoch in secret for proactive refresh

[HaoXuAI]

Problem

When the credential_chain provider creates a secret with web_identity or sts chains, the STS response includes an Expiration timestamp — but the extension only stores key_id, secret, and session_token. The expiration is discarded.

Consumers (e.g., duckdb-iceberg) that need to refresh credentials have no way to know when they expire, and must resort to fixed-interval timers (e.g., refresh every 300s regardless of actual TTL).

Fix

Store credentials.GetExpiration() as expiration_epoch (epoch seconds as BIGINT) in the secret_map when the expiration is non-empty. This is backwards-compatible — existing consumers that don't read it are unaffected.

Usage by consumers

Value expiry_val;
if (kv_secret.TryGetValue("expiration_epoch", expiry_val)) {
    int64_t expires_at = expiry_val.GetValue<int64_t>();
    int64_t now = std::chrono::duration_cast<std::chrono::seconds>(
        std::chrono::system_clock::now().time_since_epoch()).count();
    int64_t ttl = expires_at - created_at;
    if ((expires_at - now) < ttl * 0.2) {
        // Refresh — less than 20% TTL remaining
    }
}

Related

• duckdb/duckdb-iceberg#1051 — credential auto-refresh for Iceberg SIGV4 (will consume this field)

[Tmonster]

thanks! Just a quick comment

[Tmonster]

Is this used consumed anywhere? We are planning on fixing up our secret refresh functionality soon, so happy to have this in, but I don't think this is inspected anywhere else (i.e duckdb-httpfs won't use it, and I don't see it used in your duckdb-iceberg PR)

[HaoXuAI]

Thanks @Tmonster .yep it's not used at all currently. But if this is supported then I can update my pr in duckdb-iceberg to use it, instead of a fixed TTL. Let me know if that makes sense or not.

[Tmonster]

That's fine then, we can iterate on this

[Tmonster]

Thanks!

[Tmonster]

That's fine then, we can iterate on this