Does q/kdb+ ever act asynchronously when synchronously instructed to write tables to disk?

I've had a strange bug pop up -- when I write to a partitioned table, then immediately after do a select on that same table, I get an error like:

./2018.04.23/ngbarx/cunadj. OS reports: Operation not permitted.

This error does not appear if, after writing the table, I wait a few seconds. This to me seems like pointing towards there being a caching situation, where q responds before an operation is complete, but afaik everything I am doing should be synchronous.

I would love to understand what I am doing wrong / what is causing this error exactly / which commands are executing asynchronously.

The horrible details:

• Am writing from Python connected to q synchronously using the qpython3 package
• The q session is launched with slaves i.e. -s 4
• To write the partitioned table, I am using the unofficial function .Q.dcfgnt which can be found here
• I write to a q session that was initialized with a database directory as is usual when dealing with partitioned tables
• After writing the table with .Q.dcfgnt, but before doing the select, I also do .Q.chk`:/db/; system"l /db/"; .Q.cn table in that order, just to be sure the table is up and ready to use in the q session. These might be both overkill and in the wrong order, but I believe they are all synchronous calls afaik, please correct me if I am wrong.
• The trigger to the error is a 10#select from table; I understand why this is a bad idea to do in general on a partitioned table, but also from my understanding it shouldn't be triggering the particular error that I am getting.