|
|
@@ -8,6 +8,24 @@ CLI on mulan: reports 2.9.0-2 to dpkg but offers the 2.11.0 relation commands
|
|
|
Everything below was reproduced against the live 2.11.0 instance today. Where I
|
|
|
could not reproduce something, I say so rather than passing on a rumour.
|
|
|
|
|
|
+## Outcome, 2026-08-11
|
|
|
+
|
|
|
+All five were addressed in 2.11.1 (`320dfca`), and item 4 turned out never to
|
|
|
+have been a defect at all. Verified against the live instance rather than taken
|
|
|
+from the commit message:
|
|
|
+
|
|
|
+| # | Finding | Outcome |
|
|
|
+| --- | --- | --- |
|
|
|
+| 1 | `relations` listed nothing | Fixed - lists correctly |
|
|
|
+| 2 | `relation-create` blamed the wrong argument | Fixed - names the offending argument and prints the correction to use |
|
|
|
+| 3 | No `unique` on `index-create` | Added - `--unique`, refused with examples when duplicates exist |
|
|
|
+| 4 | `find` had no limit or offset | Never broken. My error, twice - see below |
|
|
|
+| 5 | `password` ciphertext in version reads | Fixed - and checked in both directions, see below |
|
|
|
+
|
|
|
+On 5, the symptom is gone and the fix is not merely stuck the other way:
|
|
|
+`hasUnpublishedChanges` reads false on a published workflow and flips to true
|
|
|
+after a real edit.
|
|
|
+
|
|
|
## Confirmed problems
|
|
|
|
|
|
### 1. `relations` lists nothing while a relation exists
|
|
|
@@ -61,11 +79,29 @@ only from client code. We have three constraints we want (`users.username`,
|
|
|
`users.email`, `(projectId, name)` on `workflows`) and cannot declare any of them
|
|
|
until our client is upgraded, even though the server supports them today.
|
|
|
|
|
|
-### 4. `find` has no limit or offset
|
|
|
+### 4. `find` has no limit or offset - WRONG, WITHDRAWN
|
|
|
+
|
|
|
+**This finding was mine and it was wrong.** `--limit` already existed when I
|
|
|
+filed it; it was simply missing from `--help`, and I reported from the help text
|
|
|
+rather than trying it. Clearing 3,869 session documents took 39 rounds of
|
|
|
+find-then-remove that one `--limit` would have avoided.
|
|
|
+
|
|
|
+Worse, when I re-checked it on 2.11.1 I reported it still broken. That was a bug
|
|
|
+in my own test: the shell here is zsh, which does not word-split an unquoted
|
|
|
+parameter, so `find $C $args` with `args="--limit 3"` passed one argument
|
|
|
+`"--limit 3"` and the CLI ignored it. Every row count came back 100 and looked
|
|
|
+like confirmation. Passing the flags literally:
|
|
|
+
|
|
|
+```
|
|
|
+find ... --limit 3 -> 3 rows
|
|
|
+find ... --limit 150 -> 150 rows (not capped at 100)
|
|
|
+find ... --limit 2 --offset 0 -> exec_0013ec98..., exec_001806a9...
|
|
|
+find ... --limit 2 --offset 2 -> exec_00217216..., exec_0028c8c0...
|
|
|
+```
|
|
|
|
|
|
-`find <collection>` returns a fixed 100 with no way to page. Clearing 3,869
|
|
|
-session documents took 39 rounds of find-then-remove. A `[limit] [offset]`, or a
|
|
|
-`remove-where`, would turn routine cleanup from a scripted loop into one command.
|
|
|
+`--offset` and `--eq FIELD VALUE` are new in 2.11.1, and `--help` now documents
|
|
|
+all of them. Nothing to fix. The lesson is mine: test the thing, do not read the
|
|
|
+help and infer, and be suspicious of a negative result that arrives too neatly.
|
|
|
|
|
|
### 5. Fields named `password` are encrypted in version snapshots but not in live reads
|
|
|
|
