Initial work on managed variables #1548

alexmojaki · 2025-11-25T12:40:01Z

No description provided.

logfire/_internal/config.py

pyproject.toml

alexmojaki · 2025-11-25T12:43:35Z

logfire/_internal/config.py



+@dataclass(init=False)
+class VariablesOptions:


having both VariablesOptions and VariablesConfig is worrying

I agree, I'm assuming you understand the difference between them, do you have a suggestion for alternative naming?

logfire/_internal/config.py

logfire/_internal/main.py

logfire/variables/config.py

logfire/variables/providers/local.py

Copilot · 2025-11-25T12:56:55Z

@alexmojaki I've opened a new pull request, #1549, to work on those changes. Once the pull request is ready, I'll request review from you.

cloudflare-workers-and-pages · 2025-11-25T13:00:20Z

Deploying logfire-docs with Cloudflare Pages

Latest commit:	`5d3e20b`
Status:	✅ Deploy successful!
Preview URL:	https://39882494.logfire-docs.pages.dev
Branch Preview URL:	https://managed-variables.logfire-docs.pages.dev

View logs

logfire/variables/providers/remote.py

alexmojaki · 2025-11-25T14:27:06Z

logfire/variables/remote.py

+            # TODO: Ideally we'd be able to terminate while the following request was going even if it takes a while
+            #   Note it's far more reasonable to terminate this worker thread "gracelessly" than an OTel exporter's.
+            #   Is there anything similar to an anyio CancelScope we can use here?


i don't see any reason to try and quickly cancel things in _worker. it's a daemon thread so it won't hold up process shutdown.

Okay, I'm concluding that the point is we don't feel a need to actually join the thread at all? The main issue I see with that is potential issues in pytest with resources not getting cleaned up properly but it might be fine, I'll try to not do any joining and we can revisit this if it causes problems.

(Note to self: my main fear was that this would cause an issue with testing.)

logfire/variables/remote.py

logfire/_internal/main.py

logfire/variables/__init__.py

logfire/variables/variable.py

logfire/variables/remote.py

logfire-api/logfire_api/__init__.pyi

alexmojaki · 2025-12-05T13:17:50Z

tests/test_variables.py

+# =============================================================================
+# Test Condition Classes
+# =============================================================================
+
+
+class TestValueEquals:
+    def test_matches_when_equal(self):
+        condition = ValueEquals(attribute='plan', value='enterprise')
+        assert condition.matches({'plan': 'enterprise'}) is True
+
+    def test_no_match_when_different(self):
+        condition = ValueEquals(attribute='plan', value='enterprise')
+        assert condition.matches({'plan': 'free'}) is False
+
+    def test_no_match_when_missing(self):
+        condition = ValueEquals(attribute='plan', value='enterprise')
+        assert condition.matches({}) is False
+
+    def test_kind_discriminator(self):
+        condition = ValueEquals(attribute='plan', value='enterprise')
+        assert condition.kind == 'value-equals'


This reads like the LLM knows it's being paid by the token

logfire/variables/config.py

tests/test_variables.py

alexmojaki · 2025-12-05T13:26:14Z

logfire/variables/config.py

+VariantKey = str
+VariableName = str
+
+# TODO: Do we need to make the following dataclasses into pydantic dataclasses or BaseModels so the validators run when


yes, why not?

alexmojaki · 2025-12-05T13:36:13Z

tests/test_variables.py

+        assert len(override.conditions) == 1
+        assert override.rollout.variants == {'premium': 1.0}
+
+    def test_multiple_conditions(self):


needs to test behaviour

alexmojaki · 2025-12-05T13:44:14Z

logfire/variables/config.py

+    Rollout schedules progress through stages sequentially, with each stage having its own
+    duration, rollout configuration, and optional conditional overrides. This allows for
+    gradual rollouts where traffic percentages can increase over time.
+
+    Example: A three-stage rollout might have:
+    - Stage 1: 5% of traffic for 1 hour (canary)
+    - Stage 2: 25% of traffic for 4 hours (early adopters)
+    - Stage 3: 100% of traffic (full rollout)


i like this example better than the one in RolloutSchedule. but it makes sense for all the explanations of a schedule to be in RolloutSchedule, not here.

i don't like the idea of having to define many stages if i want a gradual rollout e.g. increase by 5% every hour. i'd rather say "increase linearly from x% to y% starting at time T over N hours".

but do you really mind if that happens in UI rather than in python struct? Doing it in UI means we can have a clean configuration option but can change the logic etc. and not require ambitious changes, doing it in struct means we need to support all the potential patterns we'd like for shorthand configuration. Happy to discuss more but I'm not convinced that a linear rollout is right most of the time, or that end users (in aggregate) won't end up needing flexibility.

alexmojaki · 2025-12-05T13:45:51Z

logfire/variables/config.py

+    #   Note: we could add this client side using the logfire query client if the token has read capability.
+    #   However, this should maybe be discouraged if it's viable to run health check queries server-side.
+    #   We could expose a `health_check` field that contains one (or more?) SQL queries, which would either be
+    #   evaluated client side or server side. However, I don't love the


yeah I think I've convinced myself that whole set of behavior can live entirely server side / in CRUD for us, and you'd use IaC if you wanted to manage it in code. And that IaC config doesn't need to live here. Maybe that would be the right way to handle all of this schedule stuff, I think we can remove it from the PR for now.

alexmojaki · 2025-12-05T13:51:02Z

logfire/variables/config.py

+    """Duration to remain in this stage before progressing to the next.
+
+    Once a stage's duration has elapsed, the schedule automatically advances to the
+    next stage. If this is the final stage and its duration has elapsed, the schedule


so does the final stage need a duration at all?

the point was that there is a meaning to the value even if it's not currently used. We can remove/comment-out all this code for now, probably makes sense to discuss how we want to handle this synchronously.

alexmojaki · 2025-12-05T13:51:38Z

logfire/variables/config.py

+    start_at: datetime | None
+    """The datetime when this schedule becomes active.
+
+    If None, the schedule is inactive and the base rollout is used.


is that useful?

do you mean None or having a way to specify the start time? It's useful to specify the start time — e.g. if you want the feature to go live tomorrow morning once the team is ready to deal with issues.

I added the ability to set it to None as a way to store the schedule on the config before you've decided precisely when you want it to go live. You could achieve this by just setting it to some time far in the future but I was also thinking this could play nice with automated rollback — if there's a failure, we update the config to have no start time here (and maybe have some other error field populated). I'm 100% open to tweaks to this.

alexmojaki · 2025-12-05T13:52:51Z

logfire/variables/config.py

+    next stage. If this is the final stage and its duration has elapsed, the schedule
+    is considered complete.
+
+    Note: Automated rollback based on error rates is only supported server-side and should


automated rollback of any kind sounds like quite an ambitious thing to implement. why are we even implementing scheduled stages right now at all? can we just get something basic out first?

I think I explained this to you elsewhere, but the point was I wanted to convince myself that we weren't going to feel the need to add/modify the config shape to support these features if/when we wanted to ship them in the future. I'm comfortable removing and/or commenting out fields/code related to this for now.

…t so pydantic-core doesn't get built

alexmojaki commented Nov 25, 2025

View reviewed changes

Copilot AI mentioned this pull request Nov 25, 2025

[WIP] Refactor managed variables implementation based on review feedback #1549

Merged

1 task

alexmojaki commented Nov 25, 2025

View reviewed changes

logfire/variables/providers/remote.py Outdated Show resolved Hide resolved

alexmojaki commented Nov 25, 2025

View reviewed changes

dmontagu added 2 commits November 25, 2025 17:03

Initial work on managed variables

51d7e48

Add docstrings

ce01469

dmontagu force-pushed the managed-variables branch from 735b295 to ce01469 Compare November 26, 2025 00:14

dmontagu added 5 commits November 25, 2025 17:21

Some renaming

e30568d

Add some documentation

166e158

Use pydantic-ai

bd0de1c

Add more docstrings

c8c1d22

Make importing work without pydantic installed

dddcb7c

alexmojaki commented Dec 1, 2025

View reviewed changes

dmontagu added 5 commits December 1, 2025 14:23

Address most recent feedback

10b7742

Minor improvements

f7a31aa

Fix imports failure when pydantic is installed

889281a

Add tests

e67159b

Merge branch 'main' into managed-variables

d114903

dmontagu marked this pull request as ready for review December 2, 2025 23:24

dmontagu and others added 5 commits December 2, 2025 17:04

Fix stubs

c7e2d11

test_config_serializable

565c587

test_config_serializable

636636f

Add scheduled rollouts

40ae76e

Add top-level var

d363e10

alexmojaki commented Dec 5, 2025

View reviewed changes

logfire-api/logfire_api/__init__.pyi Show resolved Hide resolved

alexmojaki commented Dec 5, 2025

View reviewed changes

dmontagu added 2 commits December 8, 2025 15:53

Add CLI for syncing variables

ffc636e

Add CLI for validating variables

2620c85

dmontagu added 11 commits December 9, 2025 15:12

Merge main

e4ce576

Set development version of pydantic to be less than main branch on gi…

1b8c048

…t so pydantic-core doesn't get built

Fix tests of stubs

e57e195

Fix type checking

6fd4f1e

Merge main

2e6acc6

Fix type checking

7382346

Try getting test to pass

0a4d0e6

Update a comment and remove new stubs per Alex's feedback

95e4b54

Address more Alex feedback

8a37b15

Remove TODO comment

74cff95

Comment out schedule-related stuff

5d3e20b



		@dataclass(init=False)
		class VariablesOptions:

Initial work on managed variables #1548

Are you sure you want to change the base?

Initial work on managed variables #1548

Uh oh!

Conversation

alexmojaki commented Nov 25, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI commented Nov 25, 2025

Uh oh!

cloudflare-workers-and-pages bot commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying logfire-docs with Cloudflare Pages

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmontagu Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cloudflare-workers-and-pages bot commented Nov 25, 2025 •

edited

Loading

dmontagu Dec 12, 2025 •

edited

Loading