Add preload disposable setting to global config by ben-grande · Pull Request #262 · QubesOS/qubes-desktop-linux-manager

ben-grande · 2025-05-22T15:37:23Z

ben-grande · 2025-05-23T20:30:42Z

The current behavior of preloaded disposables when changing default_dispvm needs to be defined.

Do not mess with the old default_dispvm preload-dispvm-max feature and set the new default_dispvm feature to the same as per the old one.
Set old default_dispvm preload-dispvm-max feature to 0 and set the new default_dispvm feature to the same as per the old one.
1. Marek recommended a dom0 feature default-dispvm-preload-max. I'd say that such feature must take precedence over the disposable template feature for the GUI to behave as expected by the user.

I am concerned option 1 as a user that only uses Global Config and not Qube Settings will have lingering qubes.

Option 2 seems more sane, but I don't like the last part of my proposition:

set the new default_dispvm feature to the same as per the old one

I prefer the current behavior, which is, when toggling between disposable templates, it fetches the current feature value so you can see it updating at runtime. If we consider that the selected disposable template that is being set already has preload-dispvm-max set to a number different than the default_dispvm feature, we would be modifying the value set by the user elsewhere (vm settings, qvm-features or API) to the value received from the default_dispvm, I don't think this part makes sense.

And after writing what the new value should behave like, makes me think that the old value should not be changed to 0, because the user may have set the value elsewhere.

Then, I think the default-disvpm-preload-max dom0 feature makes sense, it would avoid this problems. With this feature, I'd say that the best behavior would be:

If the disposable template is the default_dispvm, than it must respect default-disvpm-preload-max.
When changing default_dispvm:
1. The old default_dispvm will have the preload event start triggered to adapt to only having the feature preload-dispvm-max
2. The new default_dispvm will have the value the user sets for it at runtime without depending on the old default_dispvm feature value.

Or I make fetching current value code less dynamic from the current disposable template selected and enforce that it only reads and set the dom0 feature default-dispvm-preload-max.

I guess it will be easier to grasp the advantages and disadvantages when coding. Any takes?

codecov · 2025-06-03T15:18:48Z

Codecov Report

❌ Patch coverage is 98.71795% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.99%. Comparing base (3a85bee) to head (26cdf14).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
qubes_config/global_config/basics_handler.py	97.18%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #262      +/-   ##
==========================================
- Coverage   92.99%   92.99%   -0.01%     
==========================================
  Files          64       64              
  Lines       13034    13217     +183     
==========================================
+ Hits        12121    12291     +170     
- Misses        913      926      +13

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

marmarta · 2025-07-07T11:51:18Z

There was somewhere a list of supported features - for each not set, it adds expected call returning feature not found exception.

It's the ALL_KNOWN_FEATURES global in mock_app.py

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande · 2025-07-07T14:46:42Z

Depends on QubesOS/qubes-core-admin-client#369. Codecov/patch should be 100%, excluding the NotImplementedError.

marmarek · 2025-07-07T16:42:14Z

+                              <object class="GtkLabel">
+                                <property name="visible">True</property>
+                                <property name="can-focus">False</property>
+                                <property name="label" translatable="yes">Number of disposable qubes to preload from the default disposable template. The feature is deleted if the value is 0.</property>


But now it lost the info it overrides template's own value...

marmarta · 2025-07-07T17:09:35Z

+                              <object class="GtkLabel">
+                                <property name="visible">True</property>
+                                <property name="can-focus">False</property>
+                                <property name="label" translatable="yes">Number of disposable qubes to preload from the default disposable template. Takes precedence over the qube feature. The feature is deleted if the value is 0.</property>


I don't think this works. If someone set the feature manually (using qvm-features to 0), you'll get a super confusing situation where either pressing ok in config without changing anything will erase the feature or you can get 0 in two ways, one of which means something completely different from the other. If we want to have the possibility of turning this off, I think there should be a checkbox before this signifying if the feature exists or not.

something like this (sorry for doing it in a photo-of-device way, the idea is to grey out / set sensitive to False on both label and number if checkbox is unchecked)

I don't think this works. If someone set the feature manually (using qvm-features to 0), you'll get a super confusing situation where either pressing ok in config without changing anything will erase the feature or you can get 0 in two ways, one of which means something completely different from the other. If we want to have the possibility of turning this off, I think there should be a checkbox before this signifying if the feature exists or not.

Setting to 0 or '' (empty) will make the feature be deleted when saving, yes. I thought it was better this way because the global setting is an override of the local setting. I can make the feature not be deleted if the value isn't the same... but yeah, will require a checkbox to make it understandable. The scope was set on #262 (comment)

About having the possibility to turn this off..., I don't known when it is useful to turn this off, can you give an example?

It's useful to have the disposable template's own value respected again - if you have multiple disposable templates you use (for example for different purposes) it's confusing to have one of them configured in a different place.

Hm, it might be also useful to add info in qube setting of default disposable template if its own value is overridden...

Hm, it might be also useful to add info in qube setting of default disposable template if its own value is overridden...

https://github.com/QubesOS/qubes-manager/blob/064e343571aa0c7bed16bf0fe5dd1a1673e34593/ui/settingsdlg.ui#L916

https://github.com/QubesOS/qubes-manager/blob/064e343571aa0c7bed16bf0fe5dd1a1673e34593/qubesmanager/settings.py#L1113

Setting to 0 or '' (empty) will make the feature be deleted when saving, yes. I thought it was better this way because the global setting is an override of the local setting. I can make the feature not be deleted if the value isn't the same... but yeah, will require a checkbox to make it understandable. The scope was set on #262 (comment)

About having the possibility to turn this off..., I don't known when it is useful to turn this off, can you give an example?

My issue is that: if the user sets the feature to 0 with qvm-features in dom0 CLI, and opens global config, with your proposal it will look the same as if the user deleted the feature.... but those two situations can lead to vastly different system behavior (if the feature is 0, no preloaded dispvms from default dvm template will be created, if it's deleted, the feature from the template will be used, which might be any number). Thus, using 0 as a magic value here is very confusing, and can lead to unpredictable behavior; as it's a feature so it might not be set, I think that having a checkbox (representing if the feature is set or not) and a value is the best way to display this sort of config.

The checkbox cannot be before the text because it will mess up the indentation compared to the other items. Do you prefer the checkbox before or after the spin button?

ben-grande · 2025-07-09T09:52:41Z

Ready, besides the indentation...

ben-grande · 2025-07-09T12:56:34Z

Reminder to self, when the text and no limit of this GUI is accepted, adapt on qubes-manger for qubes-vm-settings also.

ben-grande · 2025-07-10T07:52:41Z

+                                  <object class="GtkLabel">
+                                    <property name="visible">True</property>
+                                    <property name="can-focus">False</property>
+                                    <property name="label" translatable="yes">Start in the background up to the given number of disposable qubes based on the default disposable template. This makes request for disposable qubes faster at the expense of consuming RAM. Will only preload as much as your system can handle. Takes precedence over the qube feature as long as the box is checked.</property>


@andrewdavidwong What do you think?

Not sure if I completely understand the context in which this will appear, but here's my suggested revision:

The maximum number of disposables that can be loaded in the background. This makes starting new disposables much faster, but each preloaded disposable will consume memory. Even if you set this number very high, Qubes OS will only ever preload as many disposables as your system can handle, so the actual number of preloaded disposables may be lower. When this setting is enabled, it takes precedence over the qube feature. All preloaded disposables will be based on the default disposable template.

What is "the qube feature"?

What is "the qube feature"?

It is a literal qube feature, as set or shown by qvm-features.

About the context, it is on global config. I think a large text is already an outlier but I am having problems making it small.

What is the relationship between this and QubesOS/qubes-issues#1512 (comment)?

It is a literal qube feature, as set or shown by qvm-features.

Hmm... Okay, in that case, here's a slight tweak:

The maximum number of disposables that can be loaded in the background. This makes starting new disposables much faster, but each preloaded disposable will consume memory. Even if you set this number very high, Qubes OS will only ever preload as many disposables as your system can handle, so the actual number of preloaded disposables may be lower. All preloaded disposables will be based on the default disposable template. When this setting is enabled, it takes precedence over the qvm-features preloaded disposable setting.

What is the relationship between this and QubesOS/qubes-issues#1512 (comment)?

That is just an idea for future releases, it wasn't coded, it was drawed and probably won't be done too soon. This version is an MVP.

Thanks for the text revision! I will work with that.

I changed the text a bit. Didn't mention qvm-features because I think it complicates for the GUI user, they don't know what qube features are so I just wrote setting.

I changed the text a bit. Didn't mention qvm-features because I think it complicates for the GUI user, they don't know what qube features are so I just wrote setting.

Not sure if it helps to clarify, but perhaps something like, "When this global setting is enabled, it takes precedence over every individual qube's specific preloaded disposable setting, if any."

But now that I think about it, shouldn't it be the other way around? (I.e., shouldn't a a more specific setting take precedence over a more general one?)

I changed the text a bit. Didn't mention qvm-features because I think it complicates for the GUI user, they don't know what qube features are so I just wrote setting.

Not sure if it helps to clarify, but perhaps something like, "When this global setting is enabled, it takes precedence over every individual qube's specific preloaded disposable setting, if any."

It only takes precedence over the disposable template.

But now that I think about it, shouldn't it be the other way around? (I.e., shouldn't a a more specific setting take precedence over a more general one?)

Normally, yes, but this global setting is not for every qube, is just for the qube that is the default_dispvm.

It only takes precedence over the disposable template.

Okay, then how about: "When this global setting is enabled, it takes precedence over the default disposable template's own preloaded disposable setting."

Normally, yes, but this global setting is not for every qube, is just for the qube that is the default_dispvm.

Okay.

ben-grande · 2025-07-10T09:22:13Z

PipelineRetry

ben-grande · 2025-07-10T09:44:43Z

PipelineRetryFailed

marmarta · 2025-07-14T16:25:42Z

                                <property name="margin-start">5</property>
                                <property name="margin-bottom">5</property>
                                <property name="has-entry">True</property>
+                                <child internal-child="entry">


why is this added?

Removed, no idea if I misclicked this on glade...

marmarta · 2025-07-14T16:26:15Z

+                              <object class="GtkLabel">
+                                <property name="visible">True</property>
+                                <property name="can-focus">False</property>
+                                <property name="label" translatable="yes">Preload disposables:</property>


Do we want "Preload disposables", or maybe more explicitly "Preload disposable qubes"?

Changed to the latter.

marmarta · 2025-07-14T16:35:15Z

+                                  <object class="GtkLabel">
+                                    <property name="visible">True</property>
+                                    <property name="can-focus">False</property>
+                                    <property name="label" translatable="yes">The maximum number of disposables that can be loaded in the background. This makes using new disposables much faster, but each preloaded disposable will consume memory. Even if you set this number very high, Qubes OS will only ever preload as many disposables as your system can handle, so the actual number of preloaded disposables may be lower. The preloaded disposables will be based on the default disposable template. When this setting is enabled, it takes precedence over the default disposable template's own preloaded disposable setting.</property>


Suggested change

<property name="label" translatable="yes">The maximum number of disposables that can be loaded in the background. This makes using new disposables much faster, but each preloaded disposable will consume memory. Even if you set this number very high, Qubes OS will only ever preload as many disposables as your system can handle, so the actual number of preloaded disposables may be lower. The preloaded disposables will be based on the default disposable template. When this setting is enabled, it takes precedence over the default disposable template's own preloaded disposable setting.</property>

<property name="label" translatable="yes">Maximum number of disposable qubes (based on default disposable template) that will be created in the background, waiting until they are needed. This improves disposable qube startup time at the cost of increased memory usage. The setting here takes precedence over individual settings of the default disposable template. </property>

This is really, really too long. I don't think the details about RAM usage are sensible here? If you think they are, please edit it down to one sentence about resource usage max.

Used you version and cut it a bit also.

As a Qubes user, I wouldn't know what The setting here takes precedence over individual settings of the default disposable template. means. "Which settings?" is what I'd be wondering.

The same setting (preload) that is available to be changed via qubes-vm-settings?

This settings takes precedence over the default disposable template's preload setting.

Is this better?

The same setting (preload) that is available to be changed via qubes-vm-settings?

This settings takes precedence over the default disposable template's preload setting.

Is this better?

Yes, but it sounds like the first "setting" should be singular.

marmarta · 2025-07-15T11:44:58Z

+                                  <object class="GtkLabel">
+                                    <property name="visible">True</property>
+                                    <property name="can-focus">False</property>
+                                    <property name="label" translatable="yes">Maximum number of disposable qubes (based on default disposable template) that will be loaded in the background. This removes fresh disposable qube startup time at the cost of increased memory usage. The setting here takes precedence over the default disposable template's individual settings.</property>


I don't love the sentence "This removes fresh disposable qube startup time at the cost of increased memory usage"; I think that we do not use the "fresh disposable qube startup time" anywhere in the docs, so it might be somewhat confusing. "This speeds up disposable qube startup at the cost of memory."?

"This speeds up disposable qube startup at the cost of memory."?

But it doesn't speed up startup time, the startup time remains the same. What it does, when requested, on the best case scenario (requesting after preload procedures have completed), is that it skips startup time.

Changed it to:

Reduces disposable qube use waiting time at the cost of increased memory usage.

What do you think? Used a similar phrase from the manual: https://github.com/QubesOS/qubes-core-admin-client/blob/68b2b3250c87ee18ed0e28b1b8e208e501d0faa9/doc/manpages/qvm-features.rst?plain=1#L450

How about something like, "Queues disposables in the background so they're available immediately, but each one uses memory."

What do you think:

Maximum number of disposable qubes (based on default disposable template) to queue in the background so they are available immediately, but each one reserves memory. This setting takes precedence over the default disposable template's individual settings.

Suggested rewording:

The maximum number of disposable qubes to queue in the background. Preloaded disposables start instantly, but each one uses memory while queued. Preloaded disposables are always based on the default disposable template. This setting takes precedence over the default disposable template's preload setting.

If you need to make it shorter, I suggest dropping the last 1-2 sentences or moving them into a nearby "?" or "i" icon tooltip.

Current text:

Maximum number of disposable qubes (based on default disposable template) to queue in the background so they are available immediately, but each one reserves memory. This setting takes precedence over the default disposable template's preload setting.

IMHO, the first sentence is awkward, because the clause after the "but" doesn't contrast with the entire clause before the "but." Also, "Maximum number of disposable qubes (based on default disposable template)" is ambiguous, since it could be interpreted to mean that the maximum number is somehow based on the default disposable template.

What do you think:

Maximum number of disposable qubes (created from the default disposable template) to queue in the background. They are available immediately, but each one reserves memory. This setting takes precedence over the default disposable template's preload setting.

Sounds good 👍

marmarta · 2025-07-15T12:08:52Z

But from user POV this is startup time: time between "I asked for a dispvm" and "I've received a dispvm".

marmarek · 2025-07-23T15:19:45Z

When you enable preload, can you make the default to "1"? To save one click when enabling the feature.

marmarek · 2025-07-23T21:35:03Z

+        defdispvm = self.defdispvm_model.get_selected()
+        preloadcheck = self.preload_dispvm_check.get_active()
+        if defdispvm and preloadcheck:
+            self.preload_dispvm_spin.set_value(self.get_current_value() or 1)


Hm, but this will change explicit 0 into 1, no?

ben-grande · 2025-07-23T21:54:16Z

Yes, I see how it is wrong now...

…

On Wed, Jul 23, 2025, 11:35 PM Marek Marczykowski-Górecki < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In qubes_config/global_config/basics_handler.py <#262 (comment)> : > + ) + + def on_defdispvm_changed(self): + defdispvm = self.defdispvm_model.get_selected() + if defdispvm: + self.preload_dispvm_check.set_sensitive(True) + self.preload_dispvm_check.set_active(self.get_feat_value() is not None) + else: + self.preload_dispvm_check.set_sensitive(False) + self.preload_dispvm_check.set_active(False) + + def on_check_changed(self, *args): # pylint: disable=unused-argument + defdispvm = self.defdispvm_model.get_selected() + preloadcheck = self.preload_dispvm_check.get_active() + if defdispvm and preloadcheck: + self.preload_dispvm_spin.set_value(self.get_current_value() or 1) Hm, but this will change explicit 0 into 1, no? — Reply to this email directly, view it on GitHub <#262 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCE2O4O2TXXSWBJQZYCXE2T3J75Z3AVCNFSM6AAAAAB5WNPV52VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTANBZGEZDMMZVGU> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

For: QubesOS/qubes-issues#1512

ben-grande · 2025-07-24T07:59:13Z

PipelineRetryFailed

ben-grande · 2025-07-24T08:14:32Z

PipelineRetryFailed

ben-grande · 2025-07-24T10:37:32Z

PipelineRetryFailed

Other disposables may be starting and those notifications may cause confusion as to why the user is seeing a disposable with a different name than what was recently shown in a notification. For: QubesOS/qubes-issues#1512

ben-grande · 2025-07-30T14:33:00Z

Finally :) !

ben-grande mentioned this pull request May 22, 2025

Preloaded disposables QubesOS/qubes-issues#1512

Open

32 tasks

ben-grande force-pushed the preload-dispvm branch from 8036850 to 34e4962 Compare May 23, 2025 20:02

ben-grande force-pushed the preload-dispvm branch from 34e4962 to 8331269 Compare May 23, 2025 20:35

ben-grande force-pushed the preload-dispvm branch 7 times, most recently from 6831449 to 41e9f2a Compare June 3, 2025 15:02

ben-grande added a commit to ben-grande/qubes-core-admin-client that referenced this pull request Jun 3, 2025

Document default_dispvm preload feature

90c8ae7

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 4, 2025

Handle global disposable preload feature

33d49de

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin-client that referenced this pull request Jun 4, 2025

Document default_dispvm preload feature

2447603

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 4, 2025

Handle global disposable preload feature

c71a19d

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 5, 2025

Handle global disposable preload feature

8c81efb

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 5, 2025

Handle global disposable preload feature

662fb94

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande force-pushed the preload-dispvm branch from 9756c12 to 7e2be8b Compare June 6, 2025 00:37

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 6, 2025

Handle global disposable preload feature

a9fb929

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 6, 2025

Handle global disposable preload feature

0dfefdc

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande changed the title ~~[WIP] Add preload disposable setting to global config~~ Add preload disposable setting to global config Jun 6, 2025

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 6, 2025

Handle global disposable preload feature

2be985a

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 6, 2025

Handle global disposable preload feature

9ebd8f2

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande added a commit to ben-grande/qubes-core-admin that referenced this pull request Jun 7, 2025

Handle global disposable preload feature

4037b66

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande mentioned this pull request Jun 7, 2025

Handle global disposable preload feature QubesOS/qubes-core-admin#686

Merged

marmarek added the openqa-pending label Jun 8, 2025

This was referenced Jun 8, 2025

Send icons for legacy X11 Apps QubesOS/qubes-gui-agent-linux#231

Merged

Automatically accept test-signed driver installation QubesOS/qubes-installer-qubes-os-windows-tools#6

Merged

Add handler for internal feature QubesOS/qubes-desktop-linux-menu#55

Merged

ben-grande added a commit to ben-grande/qubes-core-admin-client that referenced this pull request Jul 7, 2025

Register preload features for better mock handling

a4b4f01

For: QubesOS/qubes-issues#1512 For: QubesOS/qubes-desktop-linux-manager#262

ben-grande mentioned this pull request Jul 7, 2025

Register preload features for better mock handling QubesOS/qubes-core-admin-client#369

Merged

marmarek requested changes Jul 7, 2025

View reviewed changes

marmarta reviewed Jul 7, 2025

View reviewed changes

ben-grande commented Jul 10, 2025

View reviewed changes

marmarta suggested changes Jul 14, 2025

View reviewed changes

marmarta reviewed Jul 15, 2025

View reviewed changes

This was referenced Jul 20, 2025

Autostart global disposable preload QubesOS/qubes-core-admin#700

Merged

rpm: build and package debug hypervisor QubesOS/qubes-vmm-xen#170

Merged

marmarek reviewed Jul 23, 2025

View reviewed changes

Add preload disposable setting to global config

aebe185

For: QubesOS/qubes-issues#1512

Notify usage of preloaded disposable

26cdf14

Other disposables may be starting and those notifications may cause confusion as to why the user is seeing a disposable with a different name than what was recently shown in a notification. For: QubesOS/qubes-issues#1512

marmarek approved these changes Jul 30, 2025

View reviewed changes

Conversation

ben-grande commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ben-grande commented May 23, 2025

Uh oh!

codecov Bot commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

marmarta commented Jul 7, 2025

Uh oh!

ben-grande commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

ben-grande commented Jul 9, 2025

Uh oh!

ben-grande commented Jul 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewdavidwong Jul 11, 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!

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!

andrewdavidwong Jul 13, 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!

ben-grande commented Jul 10, 2025

Uh oh!

ben-grande commented Jul 10, 2025

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

ben-grande commented May 22, 2025 •

edited

Loading

codecov Bot commented Jun 3, 2025 •

edited

Loading

ben-grande commented Jul 7, 2025 •

edited

Loading

andrewdavidwong Jul 11, 2025 •

edited

Loading

andrewdavidwong Jul 13, 2025 •

edited

Loading