eemario commented on code in PR #1386: URL: https://github.com/apache/flink-agents/pull/1386#discussion_r4560122357
########## docs/content/docs/operations/configuration.md: ########## @@ -31,6 +31,14 @@ from YAML. Environment settings apply to Agents added to that environment. YAML settings apply to jobs that load the same file. +Framework durations use `java.time.Duration` in Java and `datetime.timedelta` in +Python. In YAML, write an integer and a unit, for example `30 s`, `5 min`, or +`-1 ms`. A unit is required. Recognized units are `ns`, `us`, `ms`, `s`, `min` +(`m` means minutes), `h`, and `d`, including longer forms such as `seconds` and +`milliseconds`. The value must be a whole number of microseconds. The keys +`async.batch.timeout.ms` and `short-term-memory.state-ttl.ms` are unsupported; Review Comment: Since backward compatibility is not required here, we should remove references to the old configuration names from the code, comments, and documentation, and describe only the new configuration. ########## docs/content/docs/operations/configuration.md: ########## @@ -219,7 +227,7 @@ for retry metrics. | `decision.async` | true | boolean | Enable durable async execution for built-in Decision Model calls. `false` selects synchronous execution. | | `max-retries` | 0 | int | Maximum retries after the initial attempt of a built-in Chat or Decision Model call, including routing judge calls. Non-positive values disable retries. | | `rag.async` | true | boolean | Enable durable async execution for vector-store queries made by the built-in context retrieval Action. `false` selects synchronous execution. | -| `retry-wait-interval` | 1 | int | Base wait in seconds between retries controlled by `max-retries`. The wait before retry N is `retry-wait-interval * 2^(N-1)`. Non-positive values retry without waiting. | +| `retry-wait-interval` | `1 s` | duration | Base wait between retries controlled by `max-retries`. The wait before retry N is this duration multiplied by `2^(N-1)`. A zero or negative duration retries without waiting. | Review Comment: Could we document the effective precision of each configuration option, perhaps retaining the original precision, and consider adding validation with clear error messages where needed? The shared parser's microsecond precision looks fine; the concern is how individual consumers handle finer-grained values. For example, as sangkyoonnam pointed out, positive TTLs below 1 ms fail. For TTLs above 1 ms, any sub-millisecond remainder is silently truncated. Java retry waits truncate to milliseconds while Python retains microseconds, and both truncate each wait to whole seconds when accumulating retry statistics, potentially undercounting the total wait time. What do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
