Intermittently receive the message `error reading from or writing to noms: new manifest created with non 0 lock` when running dolt in docker.

[n0mn0m]

We have a docker image we have used for most of this year when running integration test with dolt (plan on switching to the official image, but we've had this in place for a while, and priorities 😄 ) .

FROM debian

ENV DOLT_ENABLE_TRANSACTIONS=true

RUN apt update \
  && apt install -y curl \
  && curl -L https://github.com/dolthub/dolt/releases/latest/download/install.sh | bash

COPY ./config/dolt.yml /opt/dolt/
COPY ./config/certs/server-key.pem /opt/dolt/
COPY ./config/certs/server-cert.pem /opt/dolt/

RUN useradd -r -m -d /var/lib/doltdb dolt
RUN chown -R dolt:root /opt/dolt
USER dolt

WORKDIR /var/lib/doltdb/

RUN dolt config --global --add user.name "foo" \
  && dolt config --global --add user.email "[email protected]"

RUN mkdir -p /var/lib/doltdb/foo \
  && cd foo \
  && dolt init --initial-branch dev

RUN dolt sql -q 'CALL DOLT_CHECKOUT("-b", "main", HASHOF("dev"));' -b

EXPOSE 3306
ENTRYPOINT ["dolt"]
CMD ["sql-server", "--config", "/opt/dolt/dolt.yml"]

Our config looks like:

# For more info see: https://docs.dolthub.com/reference/cli#dolt-sql-server
# `log_level` - Level of logging provided. Options are: `trace`, `debug`, `info`,
#               `warning`, `error`, and `fatal`.
# `behavior.read_only` - If true database modification is disabled
# `behavior.autocommit` - If true write queries will automatically alter the working
#                         set. When working with autocommit enabled it is highly
#                         recommended that listener.max_connections be set to 1 as
#                         concurrency issues will arise otherwise
# `user.name` - The username that connections should use for authentication
# `user.password` - The password that connections should use for authentication.
# `listener.host` - The host address that the server will run on.  This may be
#                   `localhost` or an IPv4 or IPv6 address
# `listener.port` - The port that the server should listen on
# `listener.max_connections` - The number of simultaneous connections that the
#                              server will accept
# `listener.read_timeout_millis` - The number of milliseconds that the server
#                                  will wait for a read operation
# `listener.write_timeout_millis` - The number of milliseconds that the server
#                                   will wait for a write operation
# `performance.query_parallelism` - Amount of go routines spawned to process each
#                                   query
# `databases` - a list of dolt data repositories to make available as SQL databases.
#               If databases is missing or empty then the working directory must
#               be a valid dolt data repository which will be made available as
#               a SQL database
# `databases[i].path` - A path to a dolt data repository
# `databases[i].name` - The name that the database corresponding to the given
#                       path should be referenced via SQL

log_level: trace

behavior:
  read_only: false
  autocommit: false
  persistence_behavior: load
  disable_client_multi_statements: false

user:
  name: "<insert>"
  password: "<insert>"

listener:
  host: 0.0.0.0
  port: 3306
  max_connections: 100
  read_timeout_millis: 28800000
  write_timeout_millis: 28800000
  tls_key: /opt/dolt/server-key.pem
  tls_cert: /opt/dolt/server-cert.pem
  require_secure_transport: true

databases:
  - path: "/var/lib/doltdb/foo"
    name: "foo"

performance:
  query_parallelism: null

Up until last week we were able to run test continuously locally. Now however we have to reset the dolt container because after the first run the next run of the test suite will result in the following error:

Got an error creating the test database: (1105, 'error reading from or writing to noms: new manifest created with non 0 lock')

If we wipe the volume and restart the container this goes away.

[timsehn]

Interesting. This looks like it has something to do with new format. @druvv will look.

[druvv]

Hi @n0mn0m, I was able to reproduce the issue. I will update here when I have more information.

[n0mn0m]

Confirmed the 0.51.13 release fixed this and we are able to run test back to back without doing a container/volume reset. Thanks for the fast fix.