Hey again, I don't obviously see what could be going wrong there :thinking_face: Does it return the entity okay when not using the http client lib? Are non-namespaced keyword eids working fine?

Yes the non-namespaced keyword eids work just fine.

It also throws an error via making the direct API call. Can you point out if I am doing anything wrong? The API Call:

curl --location '' \
--header 'Accept: application/edn'

you are possibly hitting some edge case from using a number for the name component of the keyword...which Clojure doesn't properly support, see https://ask.clojure.org/index.php/10225/problem-using-numbers-as-keywords

if so, I don't think XT can easily fix this without it being resolved in Clojure first

Right. Any workaround using eid-json or just eid. Or the only workaround right now is not to use number for the name component?

(xt/entity (xt/db node) (keyword "movie" "123")) This works when node is not the xtdb-http-client but a node with its own configuration.

I expect it's something getting lost in the transit encode/decode steps. Given the number is essentially stored as string anyway (keywords are handled near enough the same as strings in general), I suggest just prefixing it with an extra char would be simple enough as a workaround (xt/entity (xt/db node) (keyword "movie" (str "n" "123")))

If you leave it alone for a minute or so, do you get the command-line back? If so, it's due to agents running in the background (that a (shutdown-agents) call in -main would normally take care of).

doesn't seem to give it back... there is a lot of xtdb debug logging I see in the console and the repl, the ending output for the command line tests looks like:

2023-10-26 17:44:57,593 [main] DEBUG xtdb.system - Starting [:xtdb/node]
2023-10-26 17:44:57,593 [main] DEBUG xtdb.system - Starting [:xtdb.bus/bus-stop]
2023-10-26 17:44:57,598 [main] DEBUG xtdb.mem-kv - Using fsync on MemKv has no effect.
2023-10-26 17:44:57,598 [xtdb-standalone-submit-tx-1] DEBUG xtdb.memory - :pool-allocation-stats {:allocated 262144, :deallocated 0, :in-use 262144}
2023-10-26 17:44:57,600 [xtdb-tx-subscription-1] DEBUG xtdb.memory - :pool-allocation-stats {:allocated 393216, :deallocated 0, :in-use 393216}
2023-10-26 17:44:57,603 [main] INFO  xtdb.tx - Shut down tx-ingester

Ran 2 tests containing 1 assertions.
0 failures, 0 errors.

the last line makes me think at least a shutdown signal is being sent to the xtdb node, but not sure

It may also be futures/agents in your own code or some other library you're using. "shutdown signal [is] being sent to the xtdb node" is not what I'm talking about here, just to be clear.

gotcha, makes sense. I'll poke around further and see if I can figure out what's going on. thanks for the help!

Hey @UR5D2FW06 we had a report about something similar at the beginning of the year https://github.com/xtdb/xtdb/issues/1882 Are you running 1.24.1?

ah interesting... I tried adding the shutdown-agents call to my :once fixture, and got that working on the CLI, but then that ended up crashing my repl 🙂 FWIW, after playing around with a lot of solutions, changing my command line call from clj -X:test to clojure -A:test seemed to do the trick (command line doesn't exit and repl tests work using my code from above). Haven't had a chance yet to poke into why that may be but at least I can get back to doing stuff 🤷 . The alias for test defined in my deps.edn is just the default that comes with kit

oh and I'm on 1.23.0

looks like I can try bumping to 1.24.1 in that case

yeah looks like we fixed it a bit in 1.23.1, so worth trying the later version(s)

@UR5D2FW06 what CLI version are you using? clj -version

1.11.1.1155

OK, that's after the change of behavior in the CLI around thread pools and waiting (1.10.3.933, July 2021) but yours is still a pretty old version (August 2022). So this may be addressed by updating XTDB as above.