Discrepancies between what my app believes to have been committed and what is actually in the db

[MikeIvanichev]

Setup

Versions

• Rust: 1.85
• Diesel: 2.2.6
• Diesel_async: 0.5.2
• Database: CRDB
• Operating System Lnux (musl with jemalloc)

Feature Flags

• diesel:["postgres_backend","chrono","uuid","serde_json"]
• diesel_async:["postgres","deadpool"]

Problem Description

Hi, I'm seeing some discrepancies between what my app believes to have been committed and what is actually in the db.
Here is the relevant Rust code:

The db op:

impl<'ctx, C> Client<'ctx, C>
where
    C: AsMut<AsyncPgConnection>,
{
    pub async fn chunk_create(
        &mut self,
        id: TypedUuid<ChunkId>,
        params: params::ChunkCreate,
    ) -> Result<Chunk, Error> {
        use db_schema::chunk::dsl;

        let chunk = Chunk::new(self.ctx.tenant_id, id, params);

        self.conn
            .as_mut()
            .transaction::<_, Error, _>(|conn| {
                async move {
                    let insert = diesel::insert_into(dsl::chunk)
                        .values(&chunk)
                        .on_conflict(dsl::id)
                        .do_update()
                        .set(dsl::id.eq(excluded(dsl::id)))
                        .returning(Chunk::as_returning())
                        .get_result(conn)
                        .map_err(Error::from)
                        .boxed();

                    let (_, chunk) =
                        try_join!(tenant_check(conn, chunk.tenant_id.into()), insert)?;

                    Ok(chunk)
                }
                .scope_boxed()
            })
            .await
    }
}

And the actual Restate handler, whose result is persisted in Restate:

    async fn create(
        &self,
        ctx: ObjectContext<'_>,
        Request {
            op_ctx,
            id,
            value: params,
        }: Request<ChunkId, external::params::ChunkCreate>,
    ) -> Result<Response<db_model::Chunk>, HandlerError> {
        let chunk = ctx
            .run(|| async {
                let chunk = op_ctx
                    .graph_store(self.graph_db.get().await?)
                    .chunk_create(id, params)
                    .await
                    .map_err(HandlerError::from)?;

                Ok(Json(chunk))
            })
            .await?
            .into_inner();

        Ok(Response {
            value: chunk,
            usage: Usage::default(),
        })
    }

Restate persists the result of the handler invocation, so in this case the Ok(Response { ... }).

Restate persisted this:

{
  "value": {
    "id": "c15eaef4-18f3-0ed8-a5c7-75635a...",
    "time_created": "2025-07-10T01:40:00.129218Z",
    "time_modified": "2025-07-10T01:40:00.129218Z",
    "tenant_id": "aaad4fa2-7cf8-4249-a374-d2b549...",
    "document_id": "0196c723-ee66-3c7c-b859-f48411...",
    "customer_id": "a3186574-84f0-8791-8a16-991d14...",
    "time_from": "2025-04-22T10:53:56Z",
    "time_to": "2025-04-22T10:57:54Z",
    "content": "[ { \"speaker\": { \"...\" } } ]"
  },
  "usage": {
    "chats": {},
    "embeddings": {}
  }
}

The db does not seem to have the relevant chunk. For what it's worth, this is the time_created of some chunks that it should be amongst:

1   e915f9ec-aff7-1049-55fe-76994f006ae5   2025-07-10T01:40:03.616121Z
2   fdbb8a27-7df6-1c18-f356-e8bfba04bfb8   2025-07-10T01:39:49.862007Z
3   077aa1fe-25ac-5b88-c2d2-8a2a76b3646c   2025-07-10T01:39:49.852005Z
4   6cb50179-15ce-0be2-50ff-8f6fe39884f7   2025-07-10T01:39:49.849928Z
5   0f4a8134-6349-863c-6e42-6a9c0ccc7d89   2025-07-10T01:39:49.848033Z

Note the rather large gap in that area; this gap is rather unusual.

I know CRDB is not on the list of supported DBs, but for now I'm just looking to exonerate Diesel. Any ideas you have would be greatly appreciated if possible.

From what I can tell, this should not be caused by a dangling transaction, but I might be wrong here.

Checklist

• I have already looked over the issue tracker for similar possible closed issues.
• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate

[weiznich]

Thanks for opening this issue. Unfortunately it is as currently written not actionable in any way

• You should check if you can reproduce the issues with the latest version of diesel-async at the time of writing (0.6.1). We don't provide support for any other version
• You should check if you can reproduce the issue with an official supported database system, otherwise this is very likely an issue in CRDB which we officially support.
• If you have done both and still can reproduce the issue, we would still need a reproducible example to debug the problem. The provided code is too incomplete to say anything about whether that's a bug or not. It's not possible to even think about any sort of trouble shooting based on that as their is no way to reproduce the issue outside of your environment.