Ansible Core 2.19.0b2 has been tagged and released to PyPI. It contains a number of compatibility bugfixes, especially for callbacks that attempt to perform custom serialization of object graphs passed into the callback methods.
4 Likes
@nitzmahone this is a very interesting change and the extra security is welcome. There’s just one thing I don’t understand which is only partially documented is why ansible_managed had to go. Looks like totally unrelated to the revamp and since ansible_* is ansible’s namepace that means choosing another name and updating repositories all over the world, and everyone is gonna come up with its own flavor and roles you borrows will have their own that does not match your own etc etc That seems like quite a mess to me.
@duck-rh ansible_managed is a weird case of “we lost sight of the forest for the trees” a long time ago. People kept extending it with custom grammars (duplicating things Jinja could already do) without taking a step back to say “wait, why do we need this at all?”. It’d ultimately become a tangled overlapping mess of 3 different dynamic placeholder grammars that relied on meta-templating and was subject to template injection attacks.
If you want a fancy dynamically-calculated variable to use in your templates, well, just set one in your inventory and use it! 
In general, there’s nothing special about ansible_ prefixed vars- ansible_managed can be set as a variable anywhere you like, just like anything else. Your question did remind me of a change I forgot to include, though, which is to have the template action/lookup avoid masking ansible_managed with its calculated value if the variable already exists. That should be corrected soon via this PR - once that’s merged, you can continue to use ansible_managed in existing templates without a deprecation warning if it’s been assigned a value.
@duck-rh I’ve added some additional thoughts on the PR that makes ansible_managed var-settable if you want to weigh in there.
1 Like
@nitzmahone thanks for the reply.
I know I can add one myself but that’s not the point here. I had no idea you could customize it and I can understand this level of customization can cause problems and why you want to change it. I’m not opposed to that.
The problem is, customized or not, people are used to this variable and if they start adding new variable names all over the place then I’ll end-up with having to set a bunch or such variables to please all the third-party roles I’m using instead of a dedicated one.
As for the variable name I tend to respect namespaces because if it does not outright cause problems it might in the future. The simple fact you need to make this extra PR to remove the masking means that if it’s not magic there’s still parts of Ansible that treats it differently. If it saves me the trouble to update all the roles I created then I’ll surely give it a try but it feels like there’s still a risk.
Folks, sorry for the very stupid question here. As likely I just did some very weird mistake somewhere in dependencies…
But how actually modules and roles should be tested, if molecule run fails literally on it’s very first task?
tox -e molecule
molecule: install_deps> python -I -m pip install -r test-requirements.txt -c https://releases.openstack.org/constraints/upper/master
molecule: commands[0]> molecule test
WARNING Driver docker does not provide a schema.
INFO default scenario test matrix: dependency, cleanup, destroy, syntax, create, prepare, converge, idempotence, side_effect, verify, cleanup, destroy
INFO Performing prerun with role_name_check=0...
INFO Running default > dependency
WARNING Skipping, missing the requirements file.
Starting galaxy collection install process
[WARNING]: Collection at '/home/dr5005/.ansible/collections/ansible_collections/ah/openstack' does not have a MANIFEST.json file, nor has it galaxy.yml: cannot detect version.
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/community-general-10.6.0.tar.gz to /home/dr5005/.ansible/tmp/ansible-local-35370329k5_klmn/tmpb1tx08ut/community-general-10.6.0-eqjfzp6i
Installing 'community.general:10.6.0' to '/home/dr5005/.ansible/collections/ansible_collections/community/general'
community.general:10.6.0 was installed successfully
INFO Dependency completed successfully.
INFO Running default > cleanup
WARNING Skipping, cleanup playbook not configured.
INFO Running default > destroy
INFO Sanity checks: 'docker'
PLAY [Destroy] *****************************************************************
TASK [Set async_dir for HOME env] **********************************************
[ERROR]: Task failed: Conditional result was '/home/dr5005' of type 'str', which evaluates to True. Conditionals must have a boolean result.
Task failed.
Origin: /home/dr5005/Documents/ansible/ansible-config_template/.tox/molecule/lib/python3.11/site-packages/molecule_plugins/docker/playbooks/destroy.yml:10:7
8 - always
9 tasks:
10 - name: Set async_dir for HOME env
^ column 7
<<< caused by >>>
Conditional result was '/home/dr5005' of type 'str', which evaluates to True. Conditionals must have a boolean result.
Origin: /home/dr5005/Documents/ansible/ansible-config_template/.tox/molecule/lib/python3.11/site-packages/molecule_plugins/docker/playbooks/destroy.yml:13:13
11 ansible.builtin.set_fact:
12 ansible_async_dir: "{{ lookup('env', 'HOME') }}/.ansible_async/"
13 when: (lookup('env', 'HOME'))
^ column 13
Broken conditionals can be temporarily allowed with the `ALLOW_BROKEN_CONDITIONALS` configuration option.
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Task failed: Conditional result was '/home/dr5005' of type 'str', which evaluates to True. Conditionals must have a boolean result."}
PLAY RECAP *********************************************************************
localhost : ok=0 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0
$ .tox/molecule/bin/pip freeze
ansible-compat==25.1.5
ansible-core==2.19.0b2
ansible-lint==24.12.2
attrs==25.3.0
bashate==2.1.1
black==25.1.0
bracex==2.5.post1
certifi==2025.4.26
cffi==1.17.1
charset-normalizer==3.4.2
click==8.1.8
click-help-colors==0.9.4
coverage==7.8.0
cryptography==43.0.3
distlib==0.3.9
distro==1.9.0
docker==7.1.0
enrich==1.2.7
filelock==3.18.0
flake8==7.1.2
hacking==7.0.0
idna==3.10
importlib_metadata==8.6.1
Jinja2==3.1.6
jmespath==1.0.1
jsonschema==4.23.0
jsonschema-specifications==2025.4.1
markdown-it-py==3.0.0
MarkupSafe==3.0.2
mccabe==0.7.0
mdurl==0.1.2
molecule==25.4.0
molecule-plugins==23.7.0
mypy_extensions==1.1.0
netaddr==1.3.0
packaging==25.0
pathspec==0.12.1
pbr==6.1.1
platformdirs==4.3.7
pluggy==1.5.0
pycodestyle==2.12.1
pycparser==2.22
pyflakes==3.2.0
Pygments==2.19.1
PyYAML==6.0.2
referencing==0.36.2
requests==2.32.3
resolvelib==1.1.0
rich==14.0.0
rpds-py==0.24.0
ruamel.yaml==0.18.10
ruamel.yaml.clib==0.2.12
selinux==0.3.0
subprocess-tee==0.4.2
typing_extensions==4.13.2
urllib3==1.26.20
virtualenv==20.30.0
wcmatch==10.0
yamllint==1.37.1
zipp==3.21.0
I don’t see any un-released version of molecule or anything like that. So I’d say that it’s really worth to make test tooling compatible with the release, as I’m not sure how else to run tests otherwise:
So pretty much ironically, the first task of the test suite violates the very first change mentioned of the porting guide:
You are correct, it will also require related tooling to be updated. That repo is community owned and supported, and looks like there has been no work to begin updating it.
At a minimum, someone should file an issue with that repo to track the need for changes to be made for compatibility.
Yes, sure, the project itself is community owned, I believe. I’ve submitted the bug: Compatibility with ansible-core 2.19 · Issue #311 · ansible-community/molecule-plugins · GitHub
I just saw ssbarnea in the thread so decided to raise it here first, as I might be just missing smth.
And then - I’d guess that it’s related to the thread anyway, as this would be the blocker for quite some amount of people to start testing things, when testing suite is also not working, which might result in some extra unnecessary negativity…
I was thinking around during the evening yesterday around all these changes and required effort to get things up to par with them.
And that lead me to a question - does not this amount of breaking changes to the core, deserve a new major version?
As IMO, this kind of should have been ansible-core=3.0 instead of 2.19.
Just simply due to an established expectation that migrations between minor versions of software may contain some breaking changes, but mostly with some deprecation period.
Here we have a situation, that high majority of roles that are in wild today, are going to be broken with 2.19, just because how widespread implicit boolean conversion is (not saying about all others, which are also quite frequent).
But then also, apparently, there must be some grace period for people to get their ansible code ready and somehow explicitly mark it’s compatible with this new version. As compatibility of roles is not a given.
And apparently for people to even begin with adoption, quite some work should be done for ansible-lint, molecule, dev tools, etc.
While I think this overall rehaul brings quite good improvements, the way of releasing and handling them feels to be treated “release as usual”. While I think it totally deserves to be treated as a new major release of core instead, to bring extra awareness that there are changes implemented without any prior deprecation notices and likely to nuke existing ecosystem.
As the comparison I have in mind for this change log is Python 2.7 → 3 kinda deal.
I’m not disagreeing with what you write, but I wanted to link to a post where the versioning scheme of ansible-core is explained. Basically every 2.x.0 release is a new major release in ansible-core’s versioning system. According to that the leading 2 will only get incremented if the internal architecture of ansible-core changes, which isn’t the case.
There also was some mention of retrospectively adding warnings to ansible-core 2.18 (or even earlier?) about implicit boolean conversion, but I don’t know what happened to that (I think @nitzmahone mentioned this on Matrix). Having that ASAP would improve the situation a lot.
1 Like
Yeah, I know it was said before multiple times that it will all evolve around version 2… Does does not PRs with +29,677 −12,555 are basically changing internal architecture as well in a way? Which might fall under X as well…
But also, usually it takes a couple of days to sort out roles and code to work with new major ansible-core. In this case it feels like half a year work.
And eventually it’s stated, that work for implementation took several years as well.
So with a cycle of 6 month is not very realistic from my perspective for ecosystem to adopt to changes. And it might really ending up as ppl getting stuck on 2.18 for quite some time as it was with 2.9. And such things kinda might deserve it…
Have you run your tests against 2.19? Please share the specific issues, and people can help port the content or make the upgrade path easier.
1 Like
Hey @sivel, thanks for sharing.
I didn’t take the time to check this out until now, but I wanted to provide some feedback on this.
I’ve tested both of the examples with 2.18.6 and 2.19.0b4, the results are pretty dramatic.
I changed the sleep from 5 to 2 and it is sufficient to see the difference.
For the first example, 2.18.6 completed in 9m23s while 2.19.0b4 completed in 5m33s:
For the second example it’s more or less the same thing:
If we increase the sleep to 5 seconds the disparity increases to 19m23s (!) for 2.18.6 while 2.19.0b4 completed in 5m46s:
I didn’t dig into the specifics for now but one of the things that stood out to me when running the tests is that it seemed the templating (or running the sleep) occurred at least once per batch of forks in 2.18.6.
By this I mean that for 100 hosts and 50 forks, it would seemingly sleep twice per task.
In 2.19.0b4 it felt like it only templated the variable once at the beginning of the task and then it no longer slept.
I could confirm this with more time to test but I will leave it at this for now.
Edit: I later realized I left the sleep at 5 instead of 2 when running the second example. Oops.
1 Like
Warning, long, no glove post, but still constructive.
Ps : english is not my native language, sorry for any mistake.
Given I am using ansible since something like 2014, I have a pretty good understanding of ansible external mechanics as a user, and a portion of the internals as a dev.
And even as such, I still don’t understand a large part of the changes for v2.19,
Some of them, yes, the playbook part from porting guide for v2.19 is mostly related to nothing else than bad practice, and not even testing the inputs for at least the opposite situation.
To be honest, some of them looks like regression since ansible v2.9, like the “result.stat.exists” problem which is new to me.
Maybe because when multiple filters were removed in ~v2.5, I dropped most of the use of the “is” test, favoring instead filters like “| bool” and let the compiler do its work. I never welcomed the “is” comparator as this is usually an object comparison first, which can be hazardous.
And of course, I would really like to have a clean error instead of a java-dump-like screen due to using “json_query” in the inventory or assembling multiple variables and failing without the cause because one was not valid in the inventory but not trapped by Ansible.
But for the rest of the changes, especially the template trust model, no idea about the why, what they concretely bring to the table, and what will be the real consequences.
To be extremely blunt, to me, you are walking on very thin ice without even understanding nor seeing it, and getting slowly out of touch with your user base.
What made ansible such a success ?
Many things, but it boil down to the simplicity, not requiring an agent but only ssh, the reusability, and the extreme stability over nearly 7 years if not more.
This tool was designed to manage servers, configurations and deployments. It evolved with time, able to cover more and more stuff but still staying true to the original design.
That was the kicker.
Because the original targeted user base, which is still the main part as of today, are people working on systems and production.
They are not developers.
Most of them wouldn’t be able to do even a minor part in anything in the Ansible project itself, and for some like us who have a background in development but still sysadmin by trade, we wouldn’t be able to go very far.
Ansible was the answer to a lot of constraints where the only solution to any automation was a enormous plate of spaghetti scripts, made by people without a background in development, but able to explain at first glance why one server in a pool is badly behaving. And fix it without breaking down the whole stack.
That’s where you earnt traction.
It is still highly impressive as of today to see what can be managed with ansible and how far it can be pushed.
Up to the point I stopped trying to explain to people who still think it is impossible, I made some tools able to show them directly. Much faster.
Why I said you are slowly getting out of touch ?
It started (or was visible) with what I consider an unforgivable decision : removing the “warn” parameter of the “shell” and “command” module and making it a hard and blocking error when present.
This should have been at most only a warning in the execution and ignoring the parameter.
I created roles that exist from before ansible 2.7, pushed maybe too far, but enough to be at the point not only to manage a real production, but also building one fully from scratch. This with hundred of servers from a single ansible controller.
As of today, those roles are still able to work on both ansible 2.9 up to ansible 2.16, for both Debian and RHEL based systems.
Maintaining such consistency and stability is hard to come those days. Ansible plays a huge large part in this.
The only hicup is the need of a grep+sed+xargs command to activate or comment this “warn” parameter.
The excuse given by the ansible team was the “warn” was catched by ansible-lint.
First, not all people use ansible-lint : this is a tool for developers, which are not your main user base. It might come, but extremely slowly … or never.
Second, while I am myself using it with the “production” profile, I can tell you ansible-lint is very far to be production ready.
Too much rules that make no sense and show a real disconnect of reality, and needed rules that are missing.
Much more time and investment must be given for such a tool to be a real companion for Ansible. Currently it is just a toy, and harmful.
3 examples:
-
the “single-entry-point” rule, which by itself show very little knowledge of how things can be done neatly in reality.
I understand to discourage loading tasks from other roles, but Ansible had dedicated core modules for this, and this rule was done like a nuclear bomb for the sake of being able to say the case is covered by a rule. The whole discussion on the issue is really telling.
Fixing this will require much more work, by starting to analyze what is loaded by import_role and import_tasks, and for example, enforcing relative path to ensure the tasks files are under the same role. -
the “name[missing]” rule, required on the “import_tasks” module, making no sense as by definition “import_*” is always executed, skips or tags will be applied on the loaded subtasks. And the name might not appear on the execution.
As opposite for include_tasks, which is skippable and should have a name.
Again, a rule created for the sake of covering a case, and requiring more work to be really usable in a real world. -
the impossibility to have a real variable naming scheme.
I have learnt to code from people telling me to also type variables on their name (the hungarian notation) for multiple reasons. That sticked, even if in a less strict way.
For Ansible, I’m using a scheme in roles that people find simple, clear, and structuring :- defaults/ is dedicated to all the parameters from the inventory, and must be prefixed with the role name (ie: “my_role_”). All must be defined and with a default value.
- vars/ is for the role constants (sort of), and must be prefixed with “role_”. They must not be altered under tasks/ nor defined in the inventory.
- variables declared on the fly under tasks/ must be prefixed with “task_”
- variables declared in a single task only for itself should be prefixed with “var_” (for example when having to concatenate the same strings on multiple parameters from a loop).
Not too complex, and any problematic variable will tell you where to look at the first glance, especially when you have roles with 5+ task files and a bunch of inventory parameters because the managed application element has as much of customizable settings.
No possibility to enforce this in ansible-lint, even if partially.
Which allow me to switch to “ansible_managed” as it is following the exact same path :
I wasn’t much aware, or in fact didn’t search for what was possible to do with it in some extreme way before.
While I understand now the situation better, the proposal for removing it is really the wrong approach, not understanding how much this parameter is used, how people will not understand the change nor the reasons I’ve read in this thread and the related issue on github.
The excuses I’ve read for accepting a complete removal really show the disconnect and the contempt.
What was the original use ? Having a marker in files updated by the “template” module or others, like the “line” module telling people to not mess with said files.
Anything templated by ansible will have this line, one way or another. It is mandatory when you have multiple teams of people working on the same system, and same files.
And if not the full path of the source file, having at least the role name that was responsible for their content.
The solution to clean most of the mess would be to have this parameter kept as it was from start as a template line in the ansible.cfg file, and its value set to read-only on execution, ignoring all other declaration from anywhere else (inventories, roles, …).
With a default value set to Ansible managed: do not edit directly - role: <role name when available> - file '<(role)/path/to/file>'
Or if you really don’t want the hassle, remove the possibility to customize it and set it to a static value in the code.
Hell, even drop the file path when part of a role and keep only the role name, and you’re set.
When I switched to handling the /etc/ansible directory as throwable and using git as the source (gitops), I was burnt enough with using the date/time or the role version and having many services restarting due to a change of this line when it was just a damn comment.
Obviously, using git clone or git archive on an empty dir would end with a new date/file on the files, causing an update in “ansible_managed” value when using the file dates variable in its definition.
The root of the problem in the end was not ansible_managed, and while clearly not suitable, not its default value.
=> It was myself <= by forgetting that shipped default values are not always appropriate and must be updated to suit the real needs.
The utmost priority when managing production servers is the stability. A service must not be restarted if there was no change in its configuration.
So even if a role is updated, it must have no effect if it brings no change on the managed servers.
ansible_managed must stay natively, and its definition must reflect this.
I’m drifting a little, but many problems faced those last years are from having the wrong people at the wrong job, put and chosen by someone clearly at the wrong place.
You cannot ask for a surgical coronary intervention to the heart done by a specialist of the brain, then come after complaining about any complications.
In the same manner, you cannot switch the title of someone and expect it will allow him to gain 5+ years of experience in system administration in a snap.
The explanations I’ve read really look like this to me, trying to cater to people not suited for the job, and surprised of problems while they are trigger happy with a tool they know little about it, nor wanting to understand it, used on a production environment where any mistake will bring immediate consequences.
To give a suggestion, after opening the issue related to the size of ansible 3+ package (yeah, that was me, sue me), I came to the conclusion this wasn’t the right path : too much stuff was pulled, without control.
As I already had the need to upgrade specific collections and keeping track of the versions, I had to get out of my comfort zone to drop the ansible v3+ package meant to replace ansible 2.9, and instead use ansible-core and a requirement file with only the desired collections.
Maybe it should be the more appropriate trajectory, dunno, but that helped us to clear a lot of problems, and gave much more control on what was used.
I can still go for pages, but I will conclude by this well-known definition :
Ansible it not a programming language - it’s a tool for simplifying common IT tasks.
So stick to this, and we’ll meet again in 10 years if not more, when someone will start to drift again 
Ogme, aka Daryes.
Specialist in finding viable solutions for tortuous problems.
And it might really ending up as ppl getting stuck on 2.18 for quite some time as it was with 2.9. And such things kinda might deserve it…
Unless I’m mistaken, Redhat AAP v2.5 is linked to RHEL9, both coming with ansible 2.16 as default, supported for the full duration of the releases.
Which was in a way confirmed in some issues on the ansible github that v2.16 would be something like the next LTS version when upgrading from ansible v2.9.
So if it goes the same way as ansible v2.9 and RHEL8, the ansible-core set to stay for a very long time would be v2.16.
And btw, I disagree about the minor / intermediate version accepted to be a major version : either you are semver, or you are not.
So yeah, an ansible-core v3.x it must be instead of v2.19
I ain’t reading all that, but: Ansible does not use semver for core releases, and has never claimed to. Its version scheme conveys similar semantic information, but following different rules.
3 Likes
@sivel wrote up ansible-core’s versioning scheme here: Ansible-core versioning
The ansible community package is using semantic versioning, since version 3.0.0, but ansible-core definitely does not (and never did, same as ansible before 3.0.0). Every 2.x.0 and 1.x.0 release had breaking changes, and these releases are called “major releases” in ansible-core’s versioning scheme.
1 Like
Clarifying:
- 2.5 didn’t ‘remove filters’, it removed ‘executing tests as filters’, you used to be able to run
this | testpluginas we conflated both types, after 2.5 you need to runthis is testpluginwhich was the ‘intended’ way in Jinja. - The new error format seems to be very popular with a lot of the community, but we can never please everyone and at this point we don’t expect to. In 90% of cases it is an improvement, has clearer data and more precise data, I do suspect there are cases in which it is worse, but I have not found one yet. If you did, please report it on github.
- As for the new trust model , you are correct, it is a bit technical and users like you wont care, but to make it simple, it means ‘less security issues’ which means ‘less need to update due to security patch’, this I believe you will care about.
- The thickness of the ice is relative and being ‘in touch’ with users requires them communicating, this is a universal issue as less than 10% give feedback and 90% of that is via bug reports or feature requests. Most stay silent, so we do appreciate your feedback.
- We know most users are not developers, sadly the ones that do communicate are mostly developers, we still try hard to step into those shoes.
- shell’s
warnoption, this was actually removed due to a lot of complaints from the community, they felt it was ‘too many guardrails’ and ‘needlessly noisy’ also that the list of warnings seemed very arbitrary. We follow a 4 version deprecation/removal to allow ample of time for playbook modification, you should not encounter, probably with 2.19 exception, many jumps since 2.6 that will break your playbooks unless it was an obvious bug or security issue. ansible-lintis not for ‘developers’ it is for playbook authors (which some people call developers, which is very confusing, but I’m sticking to what I think is your definition). We are aware not everyone usesansible-lint, but that is your choice, we can provide the tools, we cannot force you to use them.- As for your feedback on
ansible-lintI’ll forward that to the team in charge - ansible_managed is not really being removed, it is being altered, instead of using it’s own ‘complex templating + jinja’ to use simple jinja templating that makes it easier for authors not having to learn yet another variant. In the end it won’t be a configuration with special templating, but just a variable you can define, just like any other. Also the ‘datetime’ problem is why we changed the default a while back to not have ‘data time’ stamps.
- the Ansible community package is handle by ‘the community’, there is an elected council and they post proposals/polls and resolutions, in this very forum. I give them info/feedback when I think it is needed, but don’t interfere with their decisions. If you think the community is steering the package the wrong way, become part of it. And what you did is precisely why we created the
ansible-coreproject, not everyone wants the ‘kitchen sink’ approach and collections allow for both, yes giving choice requires you to chose, but we think this was worth it. - semver has already been handled by others, we never were, probably never will be semver.
2 Likes
If you’re interested in feedback:
- The reply of “I ain’t readin’ all that” to a guy who has been using Ansible for a long time is rude and dismissive.
- I’ve read a few posts about the templating changes in 2.19 and I still don’t really get how it might affect me, negatively or positively. Maybe if I throw one of my playbooks at a container with 2.19 on it, it’ll be clearer, but honestly I don’t quite get the use-case it’s solving for.
My role at my job is developing automations and Ansible is really, really good. I’m happy with it and I haven’t found a shortcoming I can’t overcome with it. I haven’t been able to figure out what the templating changes will do for me in my own selfish scope of how I use it, but I have the cynical worry it’ll cause a lot of effort like how the transition of Python 2 to 3 was, so I’m also kinda turning a blind eye hoping it’ll just go away and Ansible will still be great until I get replaced by AI.
1 Like
-
The ´replier´ is part of the community, not a core dev, I neither speak for them nor police their statements.. There are rules of conduct, of course, but I doubt that crosses the line. They are a frequent contributor that is doing this as volunteer work, if reading such a long post is too much for them, I have no right to complain. Also, I doubt they meant to be rude, it is probably the comment born from already being tired and looking at work they don’t want nor need to do.
-
hopefully, you’ll see 0 changes in your plays, it is a revamp of the core templating engine, we hope to remove a lot of bugs and ambiguity for play authors, strengthen security and improve performance and resource use. Sadly we are aware that fixing some bugs due to our previous handling of data types, numbers were converted to text and other such things, might create issues with things that ‘appeared to be True’ but were not. This is where we expect some plays to show errors, but they were really already broken, they just ‘ran without complaining’, while doing the wrong thing, maybe ‘the right thing’ but accidentally . We will be updating the migration guide with any examples we find, also there will be bugs and things we might break by accident, it is impossible to make changes with out that, but we have drastically increased the tests cases and coverage to minimize this as much as possible. As always, we will deal with the bugs as people open github issues to inform us.
Also I AM NOT AN AI !!!
1 Like
You’re right, my bad. I didn’t look closely enough at one of their tags and assumed they had a more official role.