Morning, back with another issue. This one's a bit more juicy (or i've fundamentally missed something in the config). I'm trying to do LOG_BASED replication with the tap-mysql from transferwise (the default one). When I do a

meltano run tap-mysql target-postgres

initially, it reads the data and inserts it. If I then make a change to the source data and rerun, nothing changes in the target. The logs say 0 rows have changed. If i put the log-level to debug, I can see it's trying to read the binlog right from the very beginning despite having a state file in

.meltano/run/tap-mysql/state.json

and in the systemdb (haven't got around to using S3 for state yet) However, at the top of the logs I can see the following:

2025-07-25T12:29:12.610596Z [debug    ] Created configuration at /projects/meltano/.meltano/run/tap-mysql/tap.12db0892-72c1-4cea-8b74-f90c28295a5e.config.json run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f
2025-07-25T12:29:12.611601Z [debug    ] Could not find tap.properties.json in /projects/meltano/.meltano/extractors/tap-mysql/tap.properties.json, skipping. run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f
2025-07-25T12:29:12.612039Z [debug    ] Could not find tap.properties.cache_key in /projects/meltano/.meltano/extractors/tap-mysql/tap.properties.cache_key, skipping. run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f
2025-07-25T12:29:12.612460Z [debug    ] Could not find state.json in /projects/meltano/.meltano/extractors/tap-mysql/state.json, skipping. run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f
2025-07-25T12:29:12.612975Z [debug    ] Could not find tap.singer_sdk_logging.json in /projects/meltano/.meltano/extractors/tap-mysql/tap.singer_sdk_logging.json, skipping. run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f
2025-07-25T12:29:12.613416Z [debug    ] Could not find tap.pipelinewise_logging.conf in /projects/meltano/.meltano/extractors/tap-mysql/tap.pipelinewise_logging.conf, skipping. run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f
2025-07-25T12:29:12.617858Z [info     ] Using systemdb state backend   run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f
2025-07-25T12:29:12.620909Z [debug    ] Using cached catalog file      run_id=307c962f-a9a5-4aaa-bf13-5c4e710dc82f

which would indicate it's going to the wrong place for the state file (and other files) as they're in

.meltano/run/...

not

.meltano/extractors/...

If it helps the debugging process, I am running this through Docker. Not sure what other debug would be relevant? My plugin config is:

plugins:
  extractors:
  - name: tap-mysql
    variant: transferwise
    pip_url:
      git+<https://github.com/transferwise/pipelinewise.git#subdirectory=singer-connectors/tap-mysql>
    select:
      - <selectors....>
    settings:
      - name: engine
        value: mysql
    metadata:
      '*':
        replication-method: LOG_BASED

Hi @Rob Norman. Which version of Meltano are you using? I worry that this may be a regression in how Meltano merges state objects, so I'm curious if this happens, e.g. in 3.8 but not in 3.6, 3.7, etc.

@Edgar Ramírez (Arch.dev) --version shows me:

task meltano -- --version
meltano, version 3.8.0

The task runs

docker run -v "{{.TASKFILE_DIR}}":/projects -w /projects/meltano meltano/meltano {{.CLI_ARGS}}

where

{{.TASKFILE_DIR}}

is the root directory (i.e my meltano project is in

./meltano

) so it mounts that as /projects and sets the working directory to

/projects/meltano

so it can be found. Do you want me to try downgrading the version of Meltano to see if I still have the same issue?