Hello everyone! I'm experiencing problems with meltano - it seems related to the postgres target. IMO - may be also related to: https://meltano.slack.com/archives/C01TCRBBJD7/p1664120890041059 ```[info ] {"type": "SCHEMA", "stream": "communications", "schema": {"properties": {"id": {"type": ["string", "null"]}, "properties": {"properties": {"createdate": {"type": ["string", "null"]}, "hs_communication_body": {"type": ["string", "null"]}, "hs_communication_channel_type": {"type": ["string", "null"]}, "hs_communication_logged_from": {"type": ["string", "null"]}, "hs_lastmodifieddate": {"type": ["string", "null"]}}, "type": ["object", "null"]}, "createdAt": {"type": ["string", "null"]}, "updatedAt": {"type": ["string", "null"]}, "archived": {"type": ["boolean", "null"]}}, "type": "object"}, "key_properties": ["id"], "bookmark_properties": ["updatedAt"]} cmd_type=elb consumer=False name=tap-hubspot producer=True stdio=stdout string_id=tap-hubspot [info ] Traceback (most recent call last): cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/bin/target-postgres", line 8, in <module> cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] sys.exit(TargetPostgres.cli()) cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/lib/python3.9/site-packages/click/core.py", line 1157, in call cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] return self.main(*args, **kwargs) cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/lib/python3.9/site-packages/click/core.py", line 1078, in main cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] rv = self.invoke(ctx) cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/lib/python3.9/site-packages/click/core.py", line 1434, in invoke cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] return ctx.invoke(self.callback, **ctx.params) cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/lib/python3.9/site-packages/click/core.py", line 783, in invoke cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] return __callback(*args, **kwargs) cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/lib/python3.9/site-packages/singer_sdk/target_base.py", line 553, in invoke cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] target.listen(file_input) cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/lib/python3.9/site-packages/singer_sdk/io_base.py", line 34, in listen cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] self._process_lines(file_input) cmd_type=elb consumer=True name=target-postgres producer=False stdio=stderr string_id=target-postgres [info ] File "/project/.meltano/loaders/target-postgres/venv/lib/python3.9/site-packages/singer_sdk/target_base.py", line 294, in _process_lines cmd_type=elb consumer=True name=target-po…

Hi @lukasz_prasol! The first debugging step would be to look at the raw output of

tap-hubspot

to rule out that the

0x8b

byte is not part of a Singer message and tell whether it's expected or not.

Unfortunately haven't found anything suspicious. The jsonl starts normally where

0x8b

represents

<

meaning probably some error in the tap. Surprisingly the problem cannot be reproduced locally. In summary: • works in local env • works in a local docker container • fails as a kubernetes job

Ok, so maybe somehow the k8s environment injects something into the targets stdin. That's truly weird 🤔