Add abstraction to RL likelihood functions #824

cpaniaguam · 2025-10-09T18:38:23Z

This pull request introduces a new log-likelihood implementation for the RLDM model, including its JAX-based abstraction and associated unit tests. The main focus is on improving the computation of trial-wise drift rates and integrating the abstraction into the broader model likelihood system. The changes are grouped into new likelihood implementation and testing.

New RLDM likelihood implementation:

Added src/hssm/likelihoods/rldm_optimized_abstraction.py with JAX-based functions for computing RLDM drift rates and log-likelihoods, including compute_v_trial_wise, compute_v_subject_wise, and factory methods for log-likelihood functions and PyTensor Ops.

Testing and validation:

Added tests/test_rldm_likelihood_abstraction.py with unit tests for the new RLDM log-likelihood abstraction, verifying correct output shapes and numerical accuracy against expected values.

…n make_rldm_logp_func

src/hssm/likelihoods/rldm_optimized_abstraction.py

cpaniaguam · 2025-10-09T18:42:54Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+# TODO[CP]: Note really sure how to adapt this function given the changes to make_rldm_logp_func
+def make_rldm_logp_op(


@digicosmos86 Due to the scope reduction, should the rest of the workflow be added here?

There should be another function in-between. Let's focus on make_rl_logp_func

tests/test_rldm_likelihood_abstraction.py

digicosmos86

So far so good! Just one observation: rldm is just one RLSSM model (you'll see more in rldm.py), so in terms of naming we should be a bit more general

src/hssm/likelihoods/rldm_optimized_abstraction.py

digicosmos86 · 2025-10-09T18:51:39Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+        action = data[:, 1]
+        rl_alpha = dist_params[0]
+        scaler = dist_params[1]
+        feedback = dist_params[-1]


Here you'd be just stacking data and dist_params together to make a matrix

Right, that's the next and more delicate change. I wanted to ensure everything was in place before tackling this.

@digicosmos86 It seems like the order in which these are coming in might be important given how they are passed to jnp.stack. What's the most intuitive order? Perhaps require (rl_alpha, scaler, action, feedback) as in the current implementation?

subj_trials = jnp.stack((rl_alpha, scaler, action, feedback), axis=1).reshape( n_participants, n_trials, -1 )

src/hssm/likelihoods/rldm_optimized_abstraction.py

digicosmos86 · 2025-10-09T18:52:55Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+# TODO[CP]: Note really sure how to adapt this function given the changes to make_rldm_logp_func
+def make_rldm_logp_op(


There should be another function in-between. Let's focus on make_rl_logp_func

src/hssm/likelihoods/rldm_optimized_abstraction.py

… in tests

… make_rldm_logp_op for clarity

codecov · 2025-10-09T19:57:04Z

Codecov Report

❌ Patch coverage is 93.98496% with 8 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/hssm/likelihoods/rldm_optimized_abstraction.py	88.33%	7 Missing ⚠️
tests/test_rldm_likelihood_abstraction.py	98.63%	1 Missing ⚠️

Files with missing lines	Coverage Δ
tests/test_rldm_likelihood_abstraction.py	`98.63% <98.63%> (ø)`
src/hssm/likelihoods/rldm_optimized_abstraction.py	`88.33% <88.33%> (ø)`

... and 14 files with indirect coverage changes

🚀 New features to boost your workflow:

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

digicosmos86 · 2025-10-14T20:19:57Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+        rl_alpha = dist_params[0]
+        scaler = dist_params[1]
+        action = data[:, 1]
+        feedback = dist_params[-1]


I have some ideas about parameter look up in dist_params for different funcitons. For now, let's work on the most general case: this function just stacks data and every vector in dist_params and make a matrix. Is this enough info to unblock you for now?

digicosmos86 · 2025-10-14T20:38:28Z

@cpaniaguam @AlexanderFengler @krishnbera: about parameter lookup that we discussed today, here's the idea:

The inner function that make_rl_logp_func accepts will have this signature: logp_subjwise_inner_func(matrix) where matrix is a 2-D matrix with a subject-wise slice of data. We can make a function decorator for the inner function that looks like this:

@rl(inputs=["response", "rl_alpha", "scaler", "feedback"], outputs=["v"])
def logp_subjwise_inner_func(matrix)
    ...

Then this makes it very explicit to everyone what the inputs and outputs of this function are. Inside the function decorator, we just attach the inputs and outputs arguments to the function itself:

def rl(inner_func, inputs, outputs):
    inner_func.inputs = inputs
    inner_func.outputs = outputs

    return inner_func

Then we can access the information inside the make_rl_logp_func like this:

def make_rl_logp_func(subject_wise, ...):
    subjwise_inputs = subject_wise.inputs
    subjwise_outputs = subject_wise.outputs
    ...

Then we can perform look up based on the information. Potentially, this also enables us to accept multiple inner functions and compose them with the LAN functions, since we know exactly what the outputs are.

Let me know what you think

…parate variables

…nts instead of fixed parameters

cpaniaguam · 2025-10-15T15:38:31Z

@cpaniaguam @AlexanderFengler @krishnbera: about parameter lookup that we discussed today, here's the idea:

The inner function that make_rl_logp_func accepts will have this signature: logp_subjwise_inner_func(matrix) where matrix is a 2-D matrix with a subject-wise slice of data. We can make a function decorator for the inner function that looks like this:
@rl(inputs=["response", "rl_alpha", "scaler", "feedback"], outputs=["v"])
def logp_subjwise_inner_func(matrix)
    ...
Then this makes it very explicit to everyone what the inputs and outputs of this function are. Inside the function decorator, we just attach the inputs and outputs arguments to the function itself:
def rl(inner_func, inputs, outputs):
    inner_func.inputs = inputs
    inner_func.outputs = outputs

    return inner_func
Then we can access the information inside the make_rl_logp_func like this:
def make_rl_logp_func(subject_wise, ...):
    subjwise_inputs = subject_wise.inputs
    subjwise_outputs = subject_wise.outputs
    ...
Then we can perform look up based on the information. Potentially, this also enables us to accept multiple inner functions and compose them with the LAN functions, since we know exactly what the outputs are.

Let me know what you think

I like this idea of attaching the metadata to the inner function. I think it's sensible and elegant.

…lumns, distribution parameters, and extra fields

…del parameters, enhancing drift rate computation for multiple participants.

…d data handling and validation

… error handling for missing required columns

digicosmos86 · 2025-10-20T18:27:04Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+def _validate_columns(
+    data_cols: list[str] | None,
+    dist_params: list[str] | None = None,
+    extra_fields: list[str] | None = None,
+) -> None:
+    """Validate that required columns are present.
+
+    Parameters
+    ----------
+    data_cols
+        List of column names available in the data matrix. May be None when
+        called from higher-level factory functions before data is fully known.
+    dist_params
+        Distribution parameter names required by the RL likelihood.
+    extra_fields
+        Additional field names required by the RL likelihood.
+    """
+    dist_params = dist_params or []
+    extra_fields = extra_fields or []
+    if data_cols is None:
+        # If data_cols is None but we have required parameters, raise early.
+        if dist_params or extra_fields:
+            raise ValueError("data_cols is None but required columns were provided.")
+        return
+    all_cols = [*dist_params, *extra_fields]
+    missing_cols = set(all_cols) - set(data_cols)
+    if missing_cols:
+        raise ValueError(
+            f"The following columns are missing from data_cols: {missing_cols}"
+        )


I like the idea of validating that the columns exist, but if we are writing make_rl_logp_func as a pure function, we won't be able to validate the columns because we don't know what the columns are

Maybe I'm missing something, but the intent of passing in data_columns is to capture what the columns in the data matrix represent.

I think the misunderstanding is the idea that data_cols = dist_params + extra_fields. Actually, data_cols only means the columns in the data object, which is the only object that is passed in as a matrix

more or less the following applies:

likelihood(data_cols|dist_params;extra_cols)

So data-cols refer to observables, dist_params are estimable parameters (even if we fix them in a given model) and extra_cols is some extra fixed set of covariates that affects the internal computation of the likelihood.

In the rl case extra_fields are the feedback vectors which are used in the scan to update v (a dist_param).

digicosmos86

Great! We are definitely on the right track here, but I still see some lingering confusion with the signature of logp() in make_rl_logp_func. As we discussed, PyMC requires it to have this signature logp(data, *dist_params, *extra_fields). See here for how it is called

digicosmos86 · 2025-10-20T18:30:24Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+        )
+
+
+def _get_column_indices(


Please see my next comment. I think this is the right idea, but I think that, rather than just returning the indices, maybe this function should return the columns. The reason is that you are looking across two objects, the data object, and a tuple of args

digicosmos86 · 2025-10-20T18:32:04Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+    # Vectorized version of  subject_wise_func to handle multiple subjects.
+    subject_wise_vmapped = jax.vmap(subject_wise_func, in_axes=0)
+
+    def logp(data) -> np.ndarray:


We can't change the signature of this function, unless we want to have a RL version of make_distribution in distribution_utils. Otherwise, like we discussed, this function will have to have logp(data, *dist_params, *extra_fields) signature

The reason I changed it to this is because when building traces jax.jit(logp) will throw a type error if any of the arguments of the function passed are not array data types.

It is safe to assume that all arguments passed to this function are arrays. Is it because some values passed to the jitted function in the tests are scalars? They should not be scalars

I'm thinking that logp(data: np.array, dist_param:list[str], extra: list[str]). In the constructor,

def make_rl_logp_func( subject_wise_func: Callable, n_participants: int, n_trials: int, data_cols: list[str] | None = None, # column names in the data matrix passed to logp dist_params: list[str] | None = None, # dist_param column names extra_fields: list[str] | None = None, # extra_fields column names )

With the last three arguments, we can do the lookup for the indices of the names in dist_params and extra_fields within data_columns. With this, one only needs the data matrix in logp so its signature can be simplified to logp(data) as all the information in args would be available in the scope of make_rl_logp_func.

This is where the misunderstanding is. data_cols contains only the name of the columns in the data matrix (the first argument passed to logp, that typically has 'rt, response' columns. It is not to be confused with the compiled matrix that we pass to the inner function

src/hssm/likelihoods/rldm_optimized_abstraction.py

digicosmos86 · 2025-10-20T18:36:01Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+    n_participants: int,
+    n_trials: int,
+    data_cols: list[str] | None = None,
+    dist_params: list[str] | None = None,


We probably shouldn't have a default as None here, since we are not replacing it within the function to have sensible defaults. Might be a good idea to make it required

The problem there is that one can't follow an argument with a default value with a required argument. Their order would need to be changed.

The order is not super important for these arguments here, but if we want to keep the order, we can handle the None inside the function

There is handling of None defaults in _validate_columns.

…alidation

…dm_setup fixture

…rldm_logp_op to Callable[..., Any]

krishnbera · 2025-10-30T15:06:24Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+from ..distribution_utils.onnx import make_jax_matrix_logp_funcs_from_onnx
+
+# Obtain the angle log-likelihood function from an ONNX model.
+angle_logp_jax_func = make_jax_matrix_logp_funcs_from_onnx(


loading the angle LAN was hardcoded since the existing likelihood used angle. But we will need to make this generic (based on the decision process defined in the rlssm model_config) and load the correct LAN based on what the user wants.

Thanks @krishnbera. This is another element to abstract as well.

krishnbera · 2025-10-30T15:44:34Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+    # Vectorized version of  subject_wise_func to handle multiple subjects.
+    subject_wise_vmapped = jax.vmap(subject_wise_func, in_axes=0)
+
+    def logp(data, *args) -> np.ndarray:


this function name should be updated since it not computing the logp?

@cpaniaguam this is basically just the update rule for the target parameter of the reinforcement learning process (v in our example model, but again, doesn't have to be that).

@krishnbera @AlexanderFengler Thanks for pointing this out. We intentionally removed a couple of steps from the true logp computation which we intend to reintroduce in a different function.

krishnbera · 2025-10-30T15:45:47Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+    Op
+        A pytensor Op that computes the log likelihood for the RLDM model.
+    """
+    logp = make_rl_logp_func(subject_wise_func, n_participants, n_trials)


Is this function meant to output the logp or drifts (v) only? I am assuming logp, right?

@cpaniaguam / @krishnbera let's put a meeting on the calendar for monday to discuss this point? ( @digicosmos86 also if you are back).

Indeed, we are aware this is computing drift rates only and some renaming of variables is necessary. The main goal of this PR is to build the abstraction and then ingest the drifts to get logp in a separate step.

@AlexanderFengler @krishnbera this is still WIP so none of the code you see is in a final reviewable state. @cpaniaguam can you change this PR to a draft so we can iterate more on it?

AlexanderFengler

Thanks @cpaniaguam clear progress. For some of the lingering misunderstandings, let's meet again to talk things through a bit more.

Would be awesome if you could make a wire diagram on how you current see the code pieces fitting together so that we can interface with and play with that during the meeting.

AlexanderFengler · 2025-11-02T02:25:36Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+)
+
+
+def annotate_function(**kwargs):


This has parallels with the decorate_simulator decorator?
Can we reuse functionality (either base that one on this one or vice versa)?

The annotate_function decorator is more generic than decorate_atomic_simulator as the latter attaches specific metadata

model_name: str, choices: list | np.ndarray | None = None, obs_dim: int = 2, # At least for now ssms models all fall under 2 obs dims

We could refactor decorate_atomic_simulator using a call to annotate_function:

def decorate_atomic_simulator( model_name: str, choices: list | np.ndarray | None = None, obs_dim: int = 2, # At least for now ssms models all fall under 2 obs dims ): choices = [-1, 1] if choices is None else choices return annotate_function( model_name=model_name, choices=choices, obs_dim=obs_dim, )

And this change should probably be introduced in a separate PR.

AlexanderFengler · 2025-11-02T02:26:56Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+
+# Inner function to compute the drift rate and update q-values for each trial.
+# This function is used with `jax.lax.scan` to process each trial in the RLDM model.
+def compute_v_trial_wise(


similar to the angle in the name, here we shouldn't hardcode _v_ in the function name.

The learning rule could be applied to any parameter, we should use a name for it that just reflects the type of updating we are doing, regardless of which parameter it is applied to.

AlexanderFengler · 2025-11-02T02:31:33Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+# their trials one by one. It uses `jax.lax.scan` to efficiently iterate over
+# the trials and compute the drift rates based on the RL parameters, actions,
+# and rewards for each trial.
+def compute_v_subject_wise(


would take out _v_ here again in the name, and also instead of subject_wise (which insinuates that it is done per subject but FOR EACH subject) rather _one_subject.

AlexanderFengler · 2025-11-02T02:37:57Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+def _validate_columns(
+    data_cols: list[str] | None,
+    dist_params: list[str] | None = None,
+    extra_fields: list[str] | None = None,
+) -> None:
+    """Validate that required columns are present.
+
+    Parameters
+    ----------
+    data_cols
+        List of column names available in the data matrix. May be None when
+        called from higher-level factory functions before data is fully known.
+    dist_params
+        Distribution parameter names required by the RL likelihood.
+    extra_fields
+        Additional field names required by the RL likelihood.
+    """
+    dist_params = dist_params or []
+    extra_fields = extra_fields or []
+    if data_cols is None:
+        # If data_cols is None but we have required parameters, raise early.
+        if dist_params or extra_fields:
+            raise ValueError("data_cols is None but required columns were provided.")
+        return
+    all_cols = [*dist_params, *extra_fields]
+    missing_cols = set(all_cols) - set(data_cols)
+    if missing_cols:
+        raise ValueError(
+            f"The following columns are missing from data_cols: {missing_cols}"
+        )


more or less the following applies:

likelihood(data_cols|dist_params;extra_cols)

So data-cols refer to observables, dist_params are estimable parameters (even if we fix them in a given model) and extra_cols is some extra fixed set of covariates that affects the internal computation of the likelihood.

In the rl case extra_fields are the feedback vectors which are used in the scan to update v (a dist_param).

AlexanderFengler · 2025-11-02T02:39:41Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+    When data_cols is None, return an empty list so that callers can defer
+    indexing until data is available.
+    """
+    if data_cols is None:


data_cols should never be None or am I missing something?

Good eye! _get_column_indices is called after a validation check on data_cols . Thanks for catching that!

AlexanderFengler · 2025-11-02T02:42:07Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+    # Vectorized version of  subject_wise_func to handle multiple subjects.
+    subject_wise_vmapped = jax.vmap(subject_wise_func, in_axes=0)
+
+    def logp(data, *args) -> np.ndarray:


@cpaniaguam this is basically just the update rule for the target parameter of the reinforcement learning process (v in our example model, but again, doesn't have to be that).

AlexanderFengler · 2025-11-02T02:43:33Z

src/hssm/likelihoods/rldm_optimized_abstraction.py

+    Op
+        A pytensor Op that computes the log likelihood for the RLDM model.
+    """
+    logp = make_rl_logp_func(subject_wise_func, n_participants, n_trials)


@cpaniaguam / @krishnbera let's put a meeting on the calendar for monday to discuss this point? ( @digicosmos86 also if you are back).

…fy logic for column index retrieval.

…uction

cpaniaguam added 5 commits October 9, 2025 11:21

Add abstraction to log-likelihood function RLDM model

75dc4d6

Add tests for JAX log-likelihood functions in RLDM model

1673910

Reduce scope to return drift rates

63ac052

Add TODO comment for adapting make_rldm_logp_op function to changes i…

54caf5c

…n make_rldm_logp_func

Drop op test for now

add487f

cpaniaguam linked an issue Oct 9, 2025 that may be closed by this pull request

Create decorator/wrapper for make_rldm_logp_func #823

Open

6 tasks

cpaniaguam requested a review from digicosmos86 October 9, 2025 18:38

cpaniaguam commented Oct 9, 2025

View reviewed changes

src/hssm/likelihoods/rldm_optimized_abstraction.py Outdated Show resolved Hide resolved

Update docstring

b241efb

cpaniaguam commented Oct 9, 2025

View reviewed changes

src/hssm/likelihoods/rldm_optimized_abstraction.py Outdated Show resolved Hide resolved

cpaniaguam commented Oct 9, 2025

View reviewed changes

tests/test_rldm_likelihood_abstraction.py Outdated Show resolved Hide resolved

cpaniaguam added 2 commits October 9, 2025 14:45

Add a blank line before the TODO comment in make_rldm_logp_op function

b0acf3a

Fix linting

6d5f76e

digicosmos86 reviewed Oct 9, 2025

View reviewed changes

cpaniaguam added 4 commits October 9, 2025 15:01

Rename make_rldm_logp_func to make_rl_logp_func and update references…

3af10da

… in tests

Rename mapping_function to subject_wise_func in make_rl_logp_func and…

d4e2f0f

… make_rldm_logp_op for clarity

Update logp docstring for clarity on RL model specification

9bd3357

Rename variable v to drift_rates in make_rl_logp_func for clarity

3e965c8

cpaniaguam requested a review from digicosmos86 October 14, 2025 16:15

cpaniaguam added 3 commits October 14, 2025 15:00

Reorder action assignment in make_rl_logp_func for clarity

132a2da

Update TODO comment for clarity on adapting make_rldm_logp_op function

4b4c2f0

Add pragma directive to make_rldm_logp_op for test coverage exclusion

9d8ed86

digicosmos86 reviewed Oct 14, 2025

View reviewed changes

cpaniaguam added 3 commits October 15, 2025 11:18

Refactor test_make_rl_logp_func to use action from data instead of se…

4d664e9

…parate variables

Refactor logp function in make_rl_logp_func to accept variable argume…

d65c3fd

…nts instead of fixed parameters

Update logp docstring

2c407e8

cpaniaguam marked this pull request as ready for review October 15, 2025 16:09

cpaniaguam added 7 commits October 20, 2025 12:53

Add column validation and index retrieval functions for data processing

f8faa92

Enhance make_rl_logp_func to accept additional parameters for data co…

25fa64e

…lumns, distribution parameters, and extra fields

Add column validation and index retrieval in make_rl_logp_func

1a1a9c6

Refactor make_rl_logp_func to accept a 2D array for trial data and mo…

ecaf7d2

…del parameters, enhancing drift rate computation for multiple participants.

Refactor test_make_rl_logp_func to use rldm_setup fixture for improve…

7a941d6

…d data handling and validation

Enhance column validation functions to handle None values and improve…

fe8ea53

… error handling for missing required columns

Format _validate_columns call for improved readability in test cases

cb720ee

cpaniaguam self-assigned this Oct 20, 2025

digicosmos86 reviewed Oct 20, 2025

View reviewed changes

cpaniaguam added 9 commits October 20, 2025 15:58

Set default data_cols in make_rl_logp_func to ["rt", "response"]

c155f91

Add annotate_function decorator to attach metadata to functions

3412c51

Refactor _get_column_indices to rename parameters for clarity

b9b7b9b

Refactor _get_column_indices to use cols_to_look_up for index retrieval

55e806b

Update make_rl_logp_func to use subject_wise_func inputs for column v…

50e7e63

…alidation

Update logp function in make_rl_logp_func to accept additional arguments

ae3d256

Add tests for annotate_function decorator to verify attribute assignment

24fe7f8

Remove dist_params and extra_fields from make_rl_logp_func call in rl…

4634748

…dm_setup fixture

Update type hint for subject_wise_func in make_rl_logp_func and make_…

127dd38

…rldm_logp_op to Callable[..., Any]

cpaniaguam requested review from AlexanderFengler, digicosmos86 and krishnbera October 24, 2025 18:10

krishnbera reviewed Oct 30, 2025

View reviewed changes

AlexanderFengler requested changes Nov 2, 2025

View reviewed changes

cpaniaguam added 4 commits November 3, 2025 13:39

Refactor _get_column_indices to remove optional parameters and simpli…

730e82a

…fy logic for column index retrieval.

Add TODO comments to reintroduce parameter handling in make_rl_logp_func

3d7ad85

Fix default value type for data_cols in make_rl_logp_func

0315fe0

Update TODO comment in make_rl_logp_func to clarify workflow reintrod…

668a940

…uction

cpaniaguam marked this pull request as draft November 3, 2025 20:49

		# TODO[CP]: Note really sure how to adapt this function given the changes to make_rldm_logp_func
		def make_rldm_logp_op(

Add abstraction to RL likelihood functions #824

Are you sure you want to change the base?

Add abstraction to RL likelihood functions #824

Uh oh!

Conversation

cpaniaguam commented Oct 9, 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!

digicosmos86 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

codecov bot commented Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

digicosmos86 commented Oct 14, 2025

Uh oh!

cpaniaguam commented Oct 15, 2025

Uh oh!

digicosmos86 Oct 20, 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!

digicosmos86 left a comment

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!

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

codecov bot commented Oct 9, 2025 •

edited

Loading

digicosmos86 Oct 20, 2025 •

edited

Loading