heptapod issueshttps://foss.heptapod.net/groups/heptapod/-/issues2022-09-27T16:14:39Zhttps://foss.heptapod.net/heptapod/heptapod/-/issues/701Comment is shown with a date in the future2022-09-27T16:14:39Zphp4fanComment is shown with a date in the future
### Summary
I posted a comment to an issue report on a project on Heptapod (namely mercurial/tortoisehg), and right after publishing my comment, it was displayed like this:
![image](/uploads/8b7799fcd28f3610f5c72f7ee665669d/image.png)...
### Summary
I posted a comment to an issue report on a project on Heptapod (namely mercurial/tortoisehg), and right after publishing my comment, it was displayed like this:
![image](/uploads/8b7799fcd28f3610f5c72f7ee665669d/image.png)
Note the date is "in 14 seconds", that is, in the future
### Steps to reproduce
I don't know if you can reproduce, as my guess is it depends on the date on your computer, i.e. on the client side (that is my guess because I can't imagine in what other way you can get such an error).
Anyway what I did to reproduce the issue was:
- comment on an issue
- look at the comment you just posted
### What is the current *bug* behavior?
The date of the comment is shown as being in the future
### What is the expected *correct* behavior?
Right after posting the comment, the date should be displayed as "just now". After a while, it should be some date and time in the past (whether it's expressed as an absolute date and time, or in terms of "XXX ago"), NEVER under any circumstances can it be in the future. I don't expect it to be 100% accurate, but I do expect not to see an impossible value.
I can imagine a couple of ways this could happen, both if the time in my computer's clock (or your server's, or both) is slightly off:
A) When you receive and store the comment, you store the date as submitted by the client, so if the client's clock is off, the date of the comment is stored wrong
B) much more likely: when displaying the date, on the client side, you compare the date of the comment as it comes from the database (which was determined by the server) with the current date from the client's clock.
Either way it's wrong. You can't ever compare two dates that come from different clocks and assume they are correctly synchronized. If you have no other option than doing that (but that's not the case), then a small error is acceptable; but saying that something happened in the future is not.
You shouldn't assume that the time on the user's computer is _even remotely_ correct. But if you do decide, for the sake of simplicity, to assume that the clock on the user's computer is _reasonably_ correct, then you have to take into account the possibility of a reasonable error, say a few seconds or minutes. That basically boils down to clamping the "time ago" value to >= zero.
If it's none of those and you are only using server-side times, as you should, then I have no idea how you can be ending up with a negative time-ago value.https://foss.heptapod.net/heptapod/omnibus-heptapod/-/issues/20Cleanup previous Heptapod Rails downloads2022-09-24T14:41:39ZGeorges RacinetCleanup previous Heptapod Rails downloadsAll downloaded Heptapod Rails tarballs are kept in the cache:
```
$ ls -alh /var/cache/omnibus/* || /bin/true
total 790M
drwxr-xr-x 1 root root 1.7K Sep 23 19:39 .
drwxr-xr-x 1 root root 10 Sep 24 14:17 ..
-rw------- 1 root root 9.9M ...All downloaded Heptapod Rails tarballs are kept in the cache:
```
$ ls -alh /var/cache/omnibus/* || /bin/true
total 790M
drwxr-xr-x 1 root root 1.7K Sep 23 19:39 .
drwxr-xr-x 1 root root 10 Sep 24 14:17 ..
-rw------- 1 root root 9.9M Sep 21 13:07 GraphicsMagick-1.3.36.tar.gz
-rw------- 1 root root 25M Sep 21 13:07 Python-3.9.9.tgz
-rw------- 1 root root 764K Sep 21 13:07 bzip2-1.0.6.tar.gz
-rw------- 1 root root 199K Sep 21 13:07 cacert-2021-09-30.pem
drwxr-xr-x 1 root root 6 Sep 21 13:08 git_cache
-rw------- 1 root root 6.8M Sep 21 13:07 gnupg-2.2.23.tar.bz2
-rw------- 1 root root 1.7M Sep 21 13:07 gpgme-1.14.0.tar.bz2
-rw------- 1 root root 50M Sep 21 13:07 grafana-7.5.15.linux-amd64.tar.gz
-rw------- 1 root root 98M Sep 22 10:55 heptapod-rails-0.33.0rc1.tar.gz
-rw------- 1 root root 98M Sep 23 19:39 heptapod-rails-0.33.0rc2.tar.gz
-rw------- 1 root root 99M Sep 21 13:08 heptapod-rails-d0d4b5e694324f385f2c93348e9f77ff207d6e87.tar.gz
-rw------- 1 root root 559K Sep 21 13:07 libassuan-2.5.3.tar.bz2
...
```
Up to now, in practice a given cache was used only for a couple Heptapod versions, and therefore it didn't matter so much.
However, with heptapod#699, this is about to change, we'll have dozens of them.https://foss.heptapod.net/heptapod/heptapod/-/issues/691Review logos and branding2024-03-21T13:42:50ZGeorges RacinetReview logos and brandingIn upstream GitLab 15.0, there is a change of logos and the way they are used in various pages, emails. There is notably a possibility to add variable text in some of the logos.
The resulting conflicting merge will necessarily need furt...In upstream GitLab 15.0, there is a change of logos and the way they are used in various pages, emails. There is notably a possibility to add variable text in some of the logos.
The resulting conflicting merge will necessarily need further fixes, assessment will better be done in a production-style installation, hence when we make some pre-0.33 Docker images.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/690Consider upstream GitLab registry statistics2024-03-21T13:42:51ZGeorges RacinetConsider upstream GitLab registry statisticsIn version 15.0, a new projects (and root namespaces?) statistics field `container_registry_size` appears, hence duplicating our own `container_registry_size_share`.
We should consider whether it is appropriate to simply drop ours. Thi...In version 15.0, a new projects (and root namespaces?) statistics field `container_registry_size` appears, hence duplicating our own `container_registry_size_share`.
We should consider whether it is appropriate to simply drop ours. This isn't a trivial question, as the deduplicating of layers might be vastly different.Heptapod 1.4https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/156People Cannot join the mattermost instance2022-12-26T12:15:41ZPierre-Yves DavidPeople Cannot join the mattermost instanceAn error occurs when they try to use the SSO option for gitlab.
I have received report from at least to people. One is @cedkAn error occurs when they try to use the SSO option for gitlab.
I have received report from at least to people. One is @cedkhttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/149Basewhat hosting request2022-08-04T02:34:20ZPaul BissexBasewhat hosting request## Description of the projects to be hosted
- Project Name: Basewhat
- Project URL: https://hg.sr.ht/~paulbissex/basewhat
- Project Maintainers: Paul Bissex
- Project License: MIT
Please explain here how they meet our current criteria....## Description of the projects to be hosted
- Project Name: Basewhat
- Project URL: https://hg.sr.ht/~paulbissex/basewhat
- Project Maintainers: Paul Bissex
- Project License: MIT
Please explain here how they meet our current criteria.
### Main criteria
- [x] Free / Open Source
- [x] main development repositories
- [x] you are an official maintainer of the project
- [x] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Additional information
Knowing this can help in case there are constraints on resources and/or
administrators availability at the time of the request. It can also help us
suggest the right solution for the needs of the project.
- is the project officially released?
Yes. https://pypi.org/project/basewhat/
- estimation of the user base if possible, or number of downloads,
reverse dependencies…
- number of maintainers and regular contributors
1
### Hosting type
What would you like to have?
- [ ] a top-level group
- [ ] a project in an existing group
- [x] just a project in your personal namespace
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)https://foss.heptapod.net/heptapod/heptapod/-/issues/687no-git: problems with default GitLab branch2022-11-28T17:01:09ZGeorges Racinetno-git: problems with default GitLab branchSee today on mercurial/mercurial-devel>:
```
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/__init__.py", line 162, in gitlab_mirror
remote: no_git.NoGitStateMaintainer(ui, repo).sync()
remote: File "/...See today on mercurial/mercurial-devel>:
```
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/__init__.py", line 162, in gitlab_mirror
remote: no_git.NoGitStateMaintainer(ui, repo).sync()
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/no_git.py", line 86, in sync
remote: self.update_gitlab_references()
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1060, in update_gitlab_references
remote: self.heptapod_apply_changes(prune_reasons, changes)
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1071, in heptapod_apply_changes
remote: self.update_default_gitlab_branch(changes)
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1132, in update_default_gitlab_branch
remote: self.set_default_gitlab_ref(new_default_ref)
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/no_git.py", line 99, in set_default_gitlab_ref
remote: b"Setting GitLab branch to %s" % new_gl_branch)
remote: TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'NoneType'
```
The root of the problem is that the stored default GitLab branch is wrong:
```
$ cat .hg/default_gitlab_branch; echo
topic/default/rhg.errors
```
and that should never have happened, but it should nevertheless get updated correctly in that case.
To complicate things further, the Rails app sees the correct default branch (`branch/default').https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/147test_repo2022-07-18T13:24:04Zlaura_wintest_repo## Description of the projects to be hosted
- Project Name:
- Project URL:
- Project Maintainers:
- Project License:
Please explain here how they meet our current criteria.
### Main criteria
- [ ] Free / Open Source
- [ ] main develo...## Description of the projects to be hosted
- Project Name:
- Project URL:
- Project Maintainers:
- Project License:
Please explain here how they meet our current criteria.
### Main criteria
- [ ] Free / Open Source
- [ ] main development repositories
- [ ] you are an official maintainer of the project
- [ ] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Additional information
Knowing this can help in case there are constraints on resources and/or
administrators availability at the time of the request. It can also help us
suggest the right solution for the needs of the project.
- is the project officially released? In downstream distributions or
packaging systems?
- estimation of the user base if possible, or number of downloads,
reverse dependencies…
- number of maintainers and regular contributors
- where is the project currently hosted? Are there issue trackers,
review systems, CI/CD to hook to or to replace somehow?
### Hosting type
What would you like to have?
- [ ] a top-level group
- [ ] a project in an existing group
- [ ] just a project in your personal namespace
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)https://foss.heptapod.net/heptapod/heptapod/-/issues/686Empty archive downloads2023-09-05T10:50:29ZGeorges RacinetEmpty archive downloads<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Regression" or "Bug" label:
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Regression
- https://...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Regression" or "Bug" label:
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Regression
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
It happens that the download links for some Mercurial projects can provide empty archives
### Steps to reproduce
1. Go to a repo, e.g. hg repo https://heptapod.host/intevation/py3o.formats
2. Press the download selection button (to the right of the branch selection)
3. Select any format and save the file.
### Example Project
This public project on heptapod.hosts exhibits the problem : https://heptapod.host/intevation/py3o.formats
As the feature is tested within Heptapod functional tests, it is almost sure not to be systematic.
### What is the current *bug* behavior?
Downloaded archive is empty
### What is the expected *correct* behavior?
An non-empty archive, the same as produced with `hg archive` on a local clone.Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/145prueba2022-07-12T19:24:27ZHenry Guerreropruebahttps://foss.heptapod.net/heptapod/heptapod-runner/-/issues/34Custom CA certificates file not used while cloning2022-07-04T12:18:39ZGeorges RacinetCustom CA certificates file not used while cloningAccording to [GitLab runner documentation](https://docs.gitlab.com/runner/configuration/tls-self-signed.html#trusting-the-certificate-for-the-other-cicd-stages), the stages that are not defined by the user configuration (source checkout,...According to [GitLab runner documentation](https://docs.gitlab.com/runner/configuration/tls-self-signed.html#trusting-the-certificate-for-the-other-cicd-stages), the stages that are not defined by the user configuration (source checkout, artefacts etc.) will use CA certificates from the `/etc/gitlab-runner/certs/ca.crt` file.
This does not happen with Mercurial cloning with the Docker helper image.
A practical case happened with pypy/pypy#371 : the initial cloning happens with a clone bundle, hosted on Cellar (Clever Cloud S3), which in turn is cached site-wide at OSUOSL with of course a custom certificate signed by the Heptapod Internal Tooling authority.
## Workaround
On top of the mount of the CA certificates bundle into the containers, one can *also* mount a HGRC snippet so that all `hg` calls use it. Extract from current configuration on the OSUOSL runners.
Here is such a snippet, as seen from one of our Docker Heptapod Runners:
```
$ sudo cat /etc/heptapod-runner/helper-containers-cacerts.hgrc
[web]
cacerts = /etc/gitlab-runner/certs/ca.crt
```
and the corresponding extract from Heptapod Runner configuration file:
```
[[runners]]
(...)
[runners.docker]
tls_verify = false
image = "debian:buster"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache", "/etc/ssl/certs/ca-certificates.crt:/etc/gitlab-runner/certs/ca.crt:ro", "/etc/heptapod-runner/helper-containers-cacerts.hgrc:/etc/mercurial/hgrc.d/cacerts.rc:ro"]
shm_size = 0
```
`/etc/ssl/certs/ca-certificates.crt` is the standard Debian system-wide bundle of trusted CA certificates, and in that case it was already prepared to include the custom CA, which is needed to pull images from registry.heptapod.nethttps://foss.heptapod.net/heptapod/heptapod/-/issues/681Branch removal by obsmarkers2024-03-21T13:27:25ZGeorges RacinetBranch removal by obsmarkersIn case a whole named branch is removed by changeset obsolescence, the corresponding GitLab branch is not removed.
As a result, the branch is lingering in the interface, and the Gitlab state file within the Mercurial repository has an en...In case a whole named branch is removed by changeset obsolescence, the corresponding GitLab branch is not removed.
As a result, the branch is lingering in the interface, and the Gitlab state file within the Mercurial repository has an entry for an obsolete changeset, which should not happen.
An example occured on this very project:
- I started the Heptapod 0.24 release branch as `heptapod-0.24` (that's a typo)
- Later on, I realised the error and rebased the changeset, with the new, correct `heptapod-0-24` branch name.
Expected behaviour: the GitLab branch should have been removed, same as if the branch was closed with `hg commit --close-branch`
This has bad consequences, see hgitaly#102Heptapod 1.3.2https://foss.heptapod.net/heptapod/hgitaly/-/issues/101CommitService: implement CheckObjectsExist2022-06-10T17:03:25ZGeorges RacinetCommitService: implement CheckObjectsExistA new method in Gitaly 14.10, does not seem to be in use yet.
Here is the [upstream MR](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4450) that introduced it.A new method in Gitaly 14.10, does not seem to be in use yet.
Here is the [upstream MR](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4450) that introduced it.https://foss.heptapod.net/heptapod/heptapod/-/issues/680Show last user to touch commit per obslog2022-06-10T05:10:15ZKim AlvefurShow last user to touch commit per obslogWhen a commit has been edited by someone other than the commit author using evolve, it could be helpful to display this somewhere prominently in order to improve clarity. E.g. during review it might be useful to know who to contact, or p...When a commit has been edited by someone other than the commit author using evolve, it could be helpful to display this somewhere prominently in order to improve clarity. E.g. during review it might be useful to know who to contact, or provide an explanation in a "wait I didn't write this" scenario.
gracinet on IRC suggested filing an issuehttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/135Hosting request for testing Mercurial2022-06-08T18:24:32ZMauro FenzioHosting request for testing Mercurial## Description of the projects to be hosted
- Project Name:RestApi
- Project URL:
- Project Maintainers:alduin791@gmail.com
- Project License:BSD
Please explain here how they meet our current criteria.
### Main criteria
- [x] Free / ...## Description of the projects to be hosted
- Project Name:RestApi
- Project URL:
- Project Maintainers:alduin791@gmail.com
- Project License:BSD
Please explain here how they meet our current criteria.
### Main criteria
- [x] Free / Open Source
- [x] main development repositories
- [x] you are an official maintainer of the project
- [x] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Additional information
Knowing this can help in case there are constraints on resources and/or
administrators availability at the time of the request. It can also help us
suggest the right solution for the needs of the project.
- is the project officially released? In downstream distributions or
packaging systems?**no**
- estimation of the user base if possible, or number of downloads,
reverse dependencies…**actualy0**
- number of maintainers and regular contributors **1 Only me**
- where is the project currently hosted? Are there issue trackers,
review systems, CI/CD to hook to or to replace somehow? **none**
### Hosting type
What would you like to have?
- [ ] a top-level group
- [ ] a project in an existing group
- [x] just a project in your personal namespace
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)https://foss.heptapod.net/heptapod/heptapod/-/issues/678Using the rebase button fails to update the current page, needs reloading2023-01-16T10:37:04ZRaphaël GomèsUsing the rebase button fails to update the current page, needs reloading### Summary
Using the "rebase" button on a MR, the loading button appears, but then the page comes back the same "rebase" button, you need to reload the page to see the "Merge when pipeline succeeds" button.
### Steps to reproduce
Reb...### Summary
Using the "rebase" button on a MR, the loading button appears, but then the page comes back the same "rebase" button, you need to reload the page to see the "Merge when pipeline succeeds" button.
### Steps to reproduce
Rebase a MR that needs rebasing, observe the button not changing to the intended state after the loading state.
### What is the expected *correct* behavior?
The AJAX request should put the MR page in the state we get after a full page reload.
#### Details about the Heptapod instance where the bug occurs
Heptapod 0.31.1 (GitLab CE 14.9.5)
Mercurial 6.1.3 / Python 3.9.13 / hg-evolve 10.5.1https://foss.heptapod.net/heptapod/heptapod/-/issues/677Useless hunks dividers in diff view between contiguous hunks2022-12-26T12:43:16ZRaphaël GomèsUseless hunks dividers in diff view between contiguous hunks### Summary
When viewing a diff, contiguous hunks are not merged in the UI, resulting in confusing (and useless) "Show 20 lines" etc. buttons between them.
### Steps to reproduce
Go to any diff with contiguous hunks like https://foss....### Summary
When viewing a diff, contiguous hunks are not merged in the UI, resulting in confusing (and useless) "Show 20 lines" etc. buttons between them.
### Steps to reproduce
Go to any diff with contiguous hunks like https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/138/diffs?commit_id=0dc5d69c179bd8ed63314210619afb3e3ac098fd and observe.
### What is the current *bug* behavior?
The "show X lines..." divider is shown between contiguous hunks
### What is the expected *correct* behavior?
Contiguous hunks should be detected and the divider should only be present when useful (including after using it to expand between two non-contiguous hunks that then become contiguous).
Seen on foss.heptapod.net (but very likely still broken in Heptapod dev itself).
Heptapod 0.31.1 (GitLab CE 14.9.5)
Mercurial 6.1.3 / Python 3.9.13 / hg-evolve 10.5.1https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/134hosting request2022-06-02T13:32:34ZNicolas Cordierhosting request## Description of the projects to be hosted
- Project Name: ADBasicAPI
- Project URL:
- Project Maintainers: nicolas.cordier@numeric-gmbh.ch
- Project License: MIT
Please explain here how they meet our current criteria.
### Main crite...## Description of the projects to be hosted
- Project Name: ADBasicAPI
- Project URL:
- Project Maintainers: nicolas.cordier@numeric-gmbh.ch
- Project License: MIT
Please explain here how they meet our current criteria.
### Main criteria
- [x] Free / Open Source
- [x] main development repositories
- [x] you are an official maintainer of the project
- [x] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Additional information
Knowing this can help in case there are constraints on resources and/or
administrators availability at the time of the request. It can also help us
suggest the right solution for the needs of the project.
- is the project officially released? In downstream distributions or
packaging systems?
**no**
- estimation of the user base if possible, or number of downloads,
reverse dependencies…
**actually, 0 except me on my servers**
- number of maintainers and regular contributors
**one**
- where is the project currently hosted? Are there issue trackers,
review systems, CI/CD to hook to or to replace somehow?
**plan to put package on Pypi**
### Hosting type
What would you like to have?
- [ ] a top-level group
- [ ] a project in an existing group
- [x] just a project in your personal namespace
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)https://foss.heptapod.net/heptapod/heptapod/-/issues/674Compare changes on "changed this line in version x of the diff" not completing2022-06-07T12:11:12ZGeorges RacinetCompare changes on "changed this line in version x of the diff" not completingIt happens for example under [this change suggestion](https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/110#note_185298): the expected diff never gets displayed, the placeholder stays forever
The corresponding async r...It happens for example under [this change suggestion](https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/110#note_185298): the expected diff never gets displayed, the placeholder stays forever
The corresponding async request is made on the `note/:id/outdated_line_change` path, e.g, `https://foss.heptapod.net/mercurial/mercurial-devel/notes/185356/outdated_line_change` and results immediately in an empty 200 response.
No log line in `exceptions_json.log`.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/133ManejoSW42022-05-25T03:40:10ZKevinCayo10ManejoSW4