Skip to content

LCORE-632: config diagram update #493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 3, 2025
Merged

LCORE-632: config diagram update #493

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file modified docs/config.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 2 additions & 0 deletions docs/config.puml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,12 +73,14 @@ class "JwtConfiguration" as src.models.config.JwtConfiguration {
username_claim : str
}
class "JwtRoleRule" as src.models.config.JwtRoleRule {
compiled_regex
Copy link
Contributor

@coderabbitai coderabbitai bot Sep 3, 2025

Choose a reason for hiding this comment

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

💡 Verification agent

🧩 Analysis chain

Mark compiled_regex as derived/transient and add an explicit type.

If this is a runtime cache of a compiled regex (not user-supplied config), document it as derived and avoid implying it’s part of the input schema. Also add the type for clarity.

Apply in-diagram tweak:

-  compiled_regex
+  /compiled_regex : Pattern[str]

Optionally add a note to the class (outside this line range):

note right of src.models.config.JwtRoleRule
  /compiled_regex is a derived cache (compiled from `value` when operator == 'regex');
  not user-configurable and not persisted.
end note

Run to verify the underlying model treats this as non-serialized (e.g., PrivateAttr or Field(exclude=True)):

🏁 Script executed:

#!/bin/bash
# Inspect model and field treatment
rg -nP -C3 'class\s+JwtRoleRule\b' --type=py
rg -nP -C2 '\bcompiled_regex\b' --type=py
rg -nP -C2 'PrivateAttr|Field\([^)]*exclude\s*=\s*(True|1)\)' --type=py

Length of output: 2451

🏁 Script executed:

#!/bin/bash
# Locate ConfigurationBase definition to confirm model base class behavior
rg -nP 'class\s+ConfigurationBase' -C5 src/models/config.py

Length of output: 303

Mark compiled_regex as a derived property in the UML and specify its return type.

The compiled_regex property is implemented with @cached_property and is not part of the Pydantic model fields (it isn’t serialized); reflect this in the diagram:

-  compiled_regex
+  /compiled_regex : Pattern[str]

Optional:

note right of src.models.config.JwtRoleRule
  /compiled_regex is a derived cache (compiled from `value` when operator == 'regex');
  not user-configurable and not persisted.
end note
🤖 Prompt for AI Agents 
In docs/config.puml around line 76, the UML currently shows compiled_regex as a
normal attribute but it is a @cached_property (not serialized) — mark it as a
derived property and indicate its return type (e.g., java.util.regex.Pattern or
simply Pattern). Update the JwtRoleRule class attribute to use a derived marker
(e.g., /compiled_regex or <<derived>> compiled_regex: Pattern) so it’s clear
it’s computed/not persisted; optionally add the provided PlantUML note to the
right of src.models.config.JwtRoleRule explaining it’s a cached/derived value
compiled from `value` when operator == 'regex' and not user-configurable or
persisted.

jsonpath : str
negate : bool
operator
roles : list[str]
value : Any
check_jsonpath() -> Self
check_regex_pattern() -> Self
Copy link
Contributor

@coderabbitai coderabbitai bot Sep 3, 2025

Choose a reason for hiding this comment

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

💡 Verification agent

🧩 Analysis chain

Clarify behavior of check_regex_pattern() and ensure it’s represented in code.

Document that it validates the pattern and populates /compiled_regex (or raises on invalid). If it only applies when operator == 'regex', state that in a note.

Run to confirm existence and expected usage:

🏁 Script executed:

#!/bin/bash
# Method presence and basic behavior hints
rg -nP -C3 'def\s+check_regex_pattern\s*\(' --type=py
# Look for compilation and caching
rg -nP -C2 're\.compile\(|compiled_regex' --type=py
# Optional: where it's invoked in config validation
rg -nP -C3 'check_regex_pattern\s*\(' --type=py

Length of output: 4140

Update docs/config.puml to clarify check_regex_pattern validation and compiled_regex behavior

  • Under check_regex_pattern() (at docs/config.puml:83), note that it uses re.compile() to validate the pattern and raises ValueError on invalid input, and only runs when operator == JsonPathOperator.MATCH (source code)
  • Add documentation for the compiled_regex cached property: returns a compiled Pattern[str] for MATCH operators (None otherwise)
🤖 Prompt for AI Agents 
In docs/config.puml around line 83, update the check_regex_pattern()
documentation to state that it validates the regex by calling re.compile() and
will raise a ValueError for invalid patterns, and that this validation is only
performed when operator == JsonPathOperator.MATCH; also add a note for the
compiled_regex cached property explaining it returns a compiled Pattern[str]
when the operator is MATCH and None for all other operators.

check_roles() -> Self
}
class "LlamaStackConfiguration" as src.models.config.LlamaStackConfiguration {
Expand Down
Loading