https://linen.dev logo
Join Slack
Powered by
I am having an issue with the salesforce tap, ```d...
# plugins-general
r
I am having an issue with the salesforce tap,
Copy code
docker exec -it meltano meltano --log-level=debug invoke --dump=catalog tap-salesforce
errors out with
Copy code
meltano.cli.utils.CliError: expected str, bytes or os.PathLike object, not NoneType
Full Trace:
Copy code
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/meltano/cli/__init__.py", line 43, in main
    cli(obj={"project": None})
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/meltano/cli/params.py", line 23, in decorate
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/meltano/cli/params.py", line 57, in decorate
    func(project, *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/meltano/cli/select.py", line 53, in select
    show(project, extractor, show_all=flags["all"])
  File "/usr/local/lib/python3.6/site-packages/meltano/cli/select.py", line 85, in show
    list_all = select_service.list_all(session)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/select_service.py", line 51, in list_all
    catalog = self.load_catalog(session)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/select_service.py", line 45, in load_catalog
    catalog_json = invoker.dump("catalog")
  File "/usr/local/lib/python3.6/site-packages/meltano/core/plugin_invoker.py", line 195, in dump
    with self._invoke():
  File "/usr/local/lib/python3.6/contextlib.py", line 81, in __enter__
    return next(self.gen)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/plugin_invoker.py", line 167, in _invoke
    with self.plugin.trigger_hooks("invoke", self, args):
  File "/usr/local/lib/python3.6/contextlib.py", line 81, in __enter__
    return next(self.gen)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/behavior/hookable.py", line 70, in trigger_hooks
    self.__class__.trigger(self, f"before_{hook_name}", *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/behavior/hookable.py", line 97, in trigger
    raise err
  File "/usr/local/lib/python3.6/site-packages/meltano/core/behavior/hookable.py", line 89, in trigger
    hook_func(target, *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/plugin/singer/tap.py", line 214, in discover_catalog_hook
    self.discover_catalog(plugin_invoker, exec_args)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/plugin/singer/tap.py", line 255, in discover_catalog
    self.run_discovery(plugin_invoker, catalog_path)
  File "/usr/local/lib/python3.6/site-packages/meltano/core/plugin/singer/tap.py", line 280, in run_discovery
    universal_newlines=True,
  File "/usr/local/lib/python3.6/site-packages/meltano/core/plugin_invoker.py", line 183, in invoke
    return subprocess.Popen(popen_args, **popen_options, env=popen_env)
  File "/usr/local/lib/python3.6/subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1275, in _execute_child
    env_list.append(k + b'=' + os.fsencode(v))
  File "/usr/local/lib/python3.6/os.py", line 800, in fsencode
    filename = fspath(filename)  # Does type-checking of `filename`.
TypeError: expected str, bytes or os.PathLike object, not NoneType
t
Can you share what your meltano.yml looks like?
r
yep
Copy code
version: 1
send_anonymous_usage_stats: false
project_id: 2a7d19e2-5c53-42b6-a741-7a28dad03cd2
discovery_url: false
plugins:
  extractors:
  - name: tap-salesforce
    variant: meltano
    pip_url: git+<https://gitlab.com/meltano/tap-salesforce.git>
    config:
      client_id: xxx
      start_date: '2021-03-01T00:00:00Z'
the discovery url was meltano.com, but I changed it to see if that might have been causing an issue
It does not look like it gets to the point where its calling salesforce
using the latest meltano docker, v.1.71
a
I think pip_url being blank might be an issue. @rohit_amarnath, can you try with a single "." in that space, just in case that's causing the problem?
r
ok, let me try that
wait, it isnt blank - it has the git+https
nope didnt like 
.
instead of the full url
it seems like its looking to write a file for the catalog, and it fails
because it wasnt explicitly specified
a
Oh, my mistake. Yes, I see the word wrap now.
r
ha, np
let me try setting the catalog explicitly
different error -
Copy code
meltano.cli.utils.CliError: Could not dump catalog: Could not find catalog file /projects/extract/tap-salesforce.catalog.json
this is the env (secrets redacted)
```{ "source_up": None, "SALESFORCE_URL": "https://test.salesforce.com/services/Soap/u/", "TAP_SALESFORCE_IS_SANDBOX": "true", "TAP_SALESFORCE_CLIENT_SECRET": "xxx", "TAP_SALESFORCE_REFRESH_TOKEN": "xxx", "MELTANO_PROJECT_ROOT": "/projects", "MELTANO_JOB_TRIGGER": "cli", "PATH": "/projects/.meltano/extractors/tap-salesforce/venv/bin/usr/local/bin/usr/local/sbin/usr/local/bin/usr/sbin/usr/bin/sbin:/bin", "HOSTNAME": "6031615f6265", "MELTANO_CLI_LOG_LEVEL": "debug", "MELTANO_LOG_LEVEL": "debug--rm", "LANG": "C.UTF-8", "GPG_KEY": "0D96DF4D4110E5C43FBFB17F2D347EA6AA65421D", "PYTHON_VERSION": "3.6.13", "PYTHON_PIP_VERSION": "21.0.1", "PYTHON_GET_PIP_URL": "https://github.com/pypa/get-pip/raw/b60e2320d9e8d02348525bd74e871e466afdf77c/get-pip.py", "PYTHON_GET_PIP_SHA256": "c3b81e5d06371e135fb3156dc7d8fd6270735088428c4a9a5ec1f342e2024565", "NODE_VERSION": "10", "HOME": "/root", "SERVER_SOFTWARE": "gunicorn/19.10.0", "MELTANO_SEND_ANONYMOUS_USAGE_STATS": "true", "MELTANO_PROJECT_ID": "2a7d19e2-5c53-42b6-a741-7a28dad03cd2", "MELTANO_DATABASE_URI": "sqlite:////projects/.meltano/meltano.db", "MELTANO_DATABASE_MAX_RETRIES": "3", "MELTANO_DATABASE_RETRY_TIMEOUT": "5", "MELTANO_PROJECT_READONLY": "false", "MELTANO_DISCOVERY_URL": "https://www.meltano.com/discovery.yml", "MELTANO_ELT_BUFFER_SIZE": "10485760", "MELTANO_UI_BIND_HOST": "0.0.0.0", "MELTANO_API_HOSTNAME": "0.0.0.0", "MELTANO_UI_BIND_PORT": "5000", "MELTANO_API_PORT": "5000", "PORT": "5000", "MELTANO_UI_SESSION_COOKIE_SECURE": "false", "MELTANO_UI_SECRET_KEY": "thisisnotapropersecretkey", "MELTANO_UI_PASSWORD_SALT": "b4c124932584ad6e69f2774a0ae5c138", "MELTANO_UI_WORKERS": "4", "WORKERS": "4", "WEB_CONCURRENCY": "4", "MELTANO_UI_FORWARDED_ALLOW_IPS": "127.0.0.1", "FORWARDED_ALLOW_IPS": "127.0.0.1", "MELTANO_UI_READONLY": "false", "MELTANO_READONLY": "false", "MELTANO_UI_AUTHENTICATION": "false", "MELTANO_AUTHENTICATION": "false", "MELTANO_UI_ANONYMOUS_READONLY": "false", "MELTANO_UI_NOTIFICATION": "false", "MELTANO_NOTIFICATION": "false", "MELTANO_UI_ANALYSIS": "true", "MAIL_SERVER": "localhost", "MELTANO_MAIL_SERVER": "localhost", "MAIL_PORT": "1025", "MELTANO_MAIL_PORT": "1025", "MAIL_DEFAULT_SENDER": "\"Meltano\" <bot@meltano.com>", "MELTANO_MAIL_DEFAULT_SENDER": "\"Meltano\" <bot@meltano.com>", "MAIL_USE_TLS": "false", "MELTANO_MAIL_USE_TLS": "false", "MAIL_DEBUG": "false", "MELTANO_MAIL_DEBUG": "false", "MELTANO_OAUTH_SERVICE_PROVIDERS": "all", "MELTANO_TRACKING_IDS_CLI": "UA-132758957-3", "MELTANO_CLI_TRACKING_ID": "UA-132758957-3", "MELTANO_TRACKING_IDS_UI": "UA-132758957-2", "MELTANO_UI_TRACKING_ID": "UA-132758957-2", "MELTANO_TRACKING_IDS_UI_EMBED": "UA-132758957-6", "MELTANO_EMBED_TRACKING_ID": "UA-132758957-6", "MELTANO_EXTRACTOR_NAME": "tap-salesforce", "MELTANO_EXTRACTOR_NAMESPACE": "tap_salesforce", "MELTANO_EXTRACTOR_VARIANT": "meltano", "TAP_SALESFORCE_CLIENT_ID": "xxx", "MELTANO_EXTRACT_CLIENT_ID": "xxx", "MELTANO_EXTRACT_CLIENT_SECRET": "yyy", "MELTANO_EXTRACT_REFRESH_TOKEN": "zzz", "TAP_SALESFORCE_START_DATE": "2021-03-01T000000Z", "MELTANO_EXTRACT_START_DATE": "2021-03-01T000000Z", "MELTANO_EXTRACT_IS_SANDBOX": "true", "TAP_SALESFORCE_API_TYPE": "REST", "MELTANO_EXTRACT_API_TYPE": "REST", "TAP_SALESFORCE_SELECT_FIELDS_BY_DEFAULT": "true", "MELTANO_EXTRACT_SELECT_FIELDS_BY_DEFAULT": "true", "TAP_SALESFORCE_STATE_MESSAGE_THRESHOLD": "1000", "MELTANO_EXTRACT_STATE_MESSAGE_THRESHOLD": "1000", "TAP_SALESFORCE_MAX_WORKERS": "8", "MELTANO_EXTRACT_MAX_WORKERS": "8", "TAP_SALESFORCE__LOAD_SCHEMA": "tap_salesforce", "MELTANO_EXTRACT__LOAD_SCHEMA": "tap_salesforce", "TAP_SALESFORCE__SELECT": "[\"Lead.*\", \"Contact.*\", \"User.*\", \"OpportunityHistory.*\", \"Account.*\", \"Opportunity.*\"]", "MELTANO_EXTRACT__SELECT": "[\"Lead.*\", \"Contact.*\", \"User.*\", \"OpportunityH…
nothing jumps out at me
t
Me either. @douwe_maan do you have an idea?
a
@rohit_amarnath It might be helpful to see the full docker run command or the docker-compose file. The most recent error looks like it might be related to the docker container not being able to "see" the file. Are you using a -v argument in docker run (or "volumes" in docker compose) to pass along any local paths you need to reference?
d
@rohit_amarnath Are you still seeing the 
expected str, bytes or os.PathLike object, not NoneType
error or are we debugging 
Could not find catalog file /projects/extract/tap-salesforce.catalog.json
now?
r
@douwe_maan the former is the error I was trying to work around.
This is the docker command
Copy code
docker run --rm --name meltano --env MELTANO_CLI_LOG_LEVEL=debug --env MELTANO_LOG_LEVEL=debug--rm -d --platform linux/amd64 -v `pwd`:/projects -p 5000:5000 -w /projects meltano/meltano
@aaronsteers 👆
this is the 
pwd
directory contents:
Copy code
README.md
analyze
env.json
extract
load
meltano.yml
model
notebook
orchestrate
requirements.txt
site.json
transform
d
@rohit_amarnath Just ahead of the 
Traceback (most recent call last):
for 
meltano.cli.utils.CliError: expected str, bytes or os.PathLike object, not NoneType
, do you see a line starting with 
Invoking:
? I'd like to know what the failing 
subprocess.run
is being called with
I've found the issue: 
subprocess.run
fails when any env var is passed with a 
None
value, and your env dump shows 
"source_up": None,
. Where is that env var coming from?
r
source_up
is from direnv
not sure why it's inside the docker container though
oh
I copied .envrc for direnv to .env
that was it
sorry about that, a bit obscure this one I am sure
d
It would be nice if Meltano would've explicitly warned you of the issue, or if it would have just stripped out env vars with 
None
values automatically. Would you mind creating an issue for that?
r
yep, let me create an issue for it
d
Thanks!
r
thank you
Is there anything special that needs to be done for very large salesforce taps? Once I got past the issue above, it creates tap.properties.json, which is about 8mb, and then it does not do anything else. I tried it both from the cli and from the ux
never mind
as soon as I finished typing that, it finished as well
I did get this -
Copy code
[2021-03-30 19:55:13,794] [23|MainThread|gunicorn.error] [CRITICAL] WORKER TIMEOUT (pid:473)
a
The salesforce scanning and post-processing is very slow due to the very large volume of data generated.
I had a salesforce catalog that was near half a million lines of json.
Are you stuck from that timeout, or does it look like it went through okay?
r
I am not completely sure. it comes back all green in the ux but the timeout is in the log
I guess I dont know what else it does
@aaronsteers for your big catalog, did you have to tweak any parameters to allow the scan and post-processing to complete normally
a
No, but this was a while back. I think the first couple times I killed it because I thought it was stuck. 🤦‍♂️ Then when I let it run it did work correctly.
r
aight
a
For comparison, most taps can run discovery in <5 seconds and “slow” is a minute or two. Salesforce is just extremely slow because you may be sometimes making tens of thousands of API calls to discover each salesforce object and then each object’s data types.
I do want to hear how it works. Hopefully the scanning went through successfully for you.
r
the json cache gets created pretty quickly. After that it seems to just sit there
I just ran
Copy code
docker exec -it meltano meltano --log-level=debug select tap-salesforce --list --all
and it has not returned yet
d
It may take a while to parse the massive catalog file
r
The 
tap.properties.json
was created at 4:08
nothing else since
the log level is debug but nothing in the log since the env output
d
That's weird
Right now I'd wait to see if it completes eventually, or if it raises an error
r
thats what I am thinking too
it hasnt failed
so lets see what it does
docker isnt doing anything on the machine, but that may also be the apple silicon. I havent been able to gauge what stresses it
it didnt seem to have done anything except come back to the command prompt, but I also was not paying attention to it. I kicked it off again
ok it finished again, but no output
would 
TAP_SALESFORCE__SELECT
MELTANO_EXTRACT__SELECT
cause the list to be filtered?
d
Those 
select
properties affect which streams and properties are selected in the generated catalog: https://meltano.com/docs/integration.html#extractor-catalog-generation You can use 
meltano select tap-salesforce --list
to learn what is currently selected. That doesn't explain why the pipeline would run for so long without showing any output though
When you say "no output", do you mean no output at all, or just "Extract & load finished!" without any additional notes from the tap or target?
If you run in debug mode, do you see any 
tap-salesforce (out)
lines in the log with SCHEMA or RECORD messages?
r
nope
just the main debug messages
Copy code
docker exec -it meltano meltano --log-level=debug select tap-salesforce --list
[2021-04-01 16:54:05,093] [1553|MainThread|root] [DEBUG] Creating engine <meltano.core.project.Project object at 0x4002294e48>@sqlite:////projects/.meltano/meltano.db
[2021-04-01 16:54:08,110] [1553|MainThread|root] [DEBUG] Created configuration at /projects/.meltano/run/tap-salesforce/tap.config.json
[2021-04-01 16:54:08,114] [1553|MainThread|root] [DEBUG] Could not find tap.properties.json in /projects/.meltano/extractors/tap-salesforce/tap.properties.json, skipping.
[2021-04-01 16:54:08,121] [1553|MainThread|root] [DEBUG] Could not find tap.properties.cache_key in /projects/.meltano/extractors/tap-salesforce/tap.properties.cache_key, skipping.
[2021-04-01 16:54:08,125] [1553|MainThread|root] [DEBUG] Could not find state.json in /projects/.meltano/extractors/tap-salesforce/state.json, skipping.
[2021-04-01 16:54:08,127] [1553|MainThread|root] [DEBUG] Cached catalog is outdated, running discovery...
[2021-04-01 16:54:08,134] [1553|MainThread|root] [DEBUG] Invoking: ['/projects/.meltano/extractors/tap-salesforce/venv/bin/tap-salesforce', '--config', '/projects/.meltano/run/tap-salesforce/tap.config.json', '--discover']
[2021-04-01 16:54:08,134] [1553|MainThread|root] [DEBUG] Env: {'SALESFORCE_URL': '<https://tes> <-snip-> 'VIRTUAL_ENV': '/projects/.meltano/extractors/tap-salesforce/venv'}
running it again
typically just returns to the command prompt after some time
the tap.properties.json does get regenerated
d
I wonder if the container is running out of memory. The target may be storing a lot of records in memory before writing them all out in a batch
r
hmm, the container does not go down, usually if there is an issue with memory the container will die. That said let me check the logs
```[2021-04-01 035003,172] [23|MainThread|gunicorn.error] [CRITICAL] WORKER TIMEOUT (pid:1249) [2021-04-01 035003,690] [23|MainThread|gunicorn.error] [CRITICAL] WORKER TIMEOUT (pid:1251) [2021-04-01 035003,701] [23|MainThread|gunicorn.error] [CRITICAL] WORKER TIMEOUT (pid:1253) [2021-04-01 035003,701] [23|MainThread|gunicorn.error] [CRITICAL] WORKER TIMEOUT (pid:1255) [2021-04-01 035003,842] [1253|MainThread|gunicorn.error] [INFO] Worker exiting (pid: 1253) [2021-04-01 035003,840] [1251|MainThread|gunicorn.error] [INFO] Worker exiting (pid: 1251) [2021-04-01 035003,841] [1249|MainThread|gunicorn.error] [INFO] Worker exiting (pid: 1249) [2021-04-01 035003,840] [1255|MainThread|gunicorn.error] [INFO] Worker exiting (pid: 1255) [2021-04-01 035005,971] [1339|MainThread|gunicorn.error] [INFO] Booting worker with pid: 1339 [2021-04-01 035005,971] [1341|MainThread|gunicorn.error] [INFO] Booting worker with pid: 1341 [2021-04-01 035005,971] [1337|MainThread|gunicorn.error] [INFO] Booting worker with pid: 1337 [2021-04-01 035005,994] [1343|MainThread|gunicorn.error] [INFO] Booting worker with pid: 1343 [2021-04-01 035009,480] [1341|MainThread|root] [DEBUG] Creating engine <meltano.core.project.Project object at 0x4003254400>@sqlite:////projects/.meltano/meltano.db [2021-04-01 035009,481] [1343|MainThread|root] [DEBUG] Creating engine <meltano.core.project.Project object at 0x4003254400>@sqlite:////projects/.meltano/meltano.db [2021-04-01 035009,485] [1337|MainThread|root] [DEBUG] Creating engine <meltano.core.project.Project object at 0x4003254400>@sqlite:////projects/.meltano/meltano.db [2021-04-01 035009,504] [1339|MainThread|root] [DEBUG] Creating engine <meltano.core.project.Project object at 0x4003254400>@sqlite:////projects/.meltano/meltano.db [2021-04-01 035010,305] [1343|MainThread|passlib.registry] [DEBUG] registered 'bcrypt' handler: <class 'passlib.handlers.bcrypt.bcrypt'> [2021-04-01 035010,317] [1341|MainThread|passlib.registry] [DEBUG] registered 'bcrypt' handler: <class 'passlib.handlers.bcrypt.bcrypt'> [2021-04-01 035010,328] [1343|MainThread|passlib.registry] [DEBUG] registered 'des_crypt' handler: <class 'passlib.handlers.des_crypt.des_crypt'> [2021-04-01 035010,333] [1343|MainThread|passlib.registry] [DEBUG] registered 'pbkdf2_sha256' handler: <class 'passlib.handlers.pbkdf2.pbkdf2_sha256'> [2021-04-01 035010,334] [1343|MainThread|passlib.registry] [DEBUG] registered 'pbkdf2_sha512' handler: <class 'passlib.handlers.pbkdf2.pbkdf2_sha512'> [2021-04-01 035010,337] [1343|MainThread|passlib.registry] [DEBUG] registered 'sha256_crypt' handler: <class 'passlib.handlers.sha2_crypt.sha256_crypt'> [2021-04-01 035010,337] [1343|MainThread|passlib.registry] [DEBUG] registered 'sha512_crypt' handler: <class 'passlib.handlers.sha2_crypt.sha512_crypt'> [2021-04-01 035010,339] [1343|MainThread|passlib.registry] [DEBUG] registered 'plaintext' handler: <class 'passlib.handlers.misc.plaintext'> [2021-04-01 035010,340] [1341|MainThread|passlib.registry] [DEBUG] registered 'des_crypt' handler: <class 'passlib.handlers.des_crypt.des_crypt'> [2021-04-01 035010,345] [1341|MainThread|passlib.registry] [DEBUG] registered 'pbkdf2_sha256' handler: <class 'passlib.handlers.pbkdf2.pbkdf2_sha256'> [2021-04-01 035010,346] [1341|MainThread|passlib.registry] [DEBUG] registered 'pbkdf2_sha512' handler: <class 'passlib.handlers.pbkdf2.pbkdf2_sha512'> [2021-04-01 035010,346] [1337|MainThread|passlib.registry] [DEBUG] registered 'bcrypt' handler: <class 'passlib.handlers.bcrypt.bcrypt'> [2021-04-01 035010,348] [1341|MainThread|passlib.registry] [DEBUG] registered 'sha256_crypt' handler: <class 'passlib.handlers.sha2_crypt.sha256_crypt'> [2021-04-01 035010,348] [1341|MainThread|passlib.registry] [DEBUG] registered 'sha512_crypt' handler: <class 'passlib.handlers.sha2_crypt.sha512_crypt'> […
maybe the worker timeouts?
d
That's the 
meltano ui
output right? I assume when you were running the pipelines earlier you were using 
meltano elt
? Can you share the full output for one of those 
meltano elt
runs? Even if it looks uninteresting or stops suddenly, the place where it stops could be enlightening
r
right now I have not run any elts. The only thing I have run is the select
(yep and that was the docker log which is the UI)
d
Aah, right. It's so odd that just selecting is taking so long/timing out. If you run 
meltano invoke tap-salesforce --discover
, does that show the same behavior? Or do you see the massive catalog printed?
r
hmm, I dont see it printed
let me try running this as an exec inside the container rather than outside
aha, so its showing more detail when I run it from inside the container
d
Oh really? That's odd
r
but not if I run it as an exec
Copy code
[2021-04-01 18:49:45,081] [1656|MainThread|root] [DEBUG] Env: {'SALESFORCE_URL': '<https://test.salesforce.com/services/Soap/u/>', <-snip-> 'VIRTUAL_ENV': '/projects/.meltano/extractors/tap-salesforce/venv'}
INFO Attempting login via OAuth2
INFO OAuth2 login successful
INFO Starting new login timer
the log seems to be different
after the Env
maybe the tap is using some other logger
it should still show on stdout though
k, now it finished dumping the json, and its waiting on something
t
d
@taylor I think we may be seeing symptoms of those issues, but it doesn't appear to the the root of the problem. @rohit_amarnath You wrote "now it finished dumping the json, and its waiting on something"; does this mean that after the JSON was dumped, the 
meltano invoke tap-salesforce --discover
still didn't complete? Did you see any more 
Starting new login timer
log lines after that? I wonder if the tap has a bug somewhere where it doesn't stop the timer once discovery is completed, and just keeps the timer going indefinitely
r
I did see the starting new login timer, but it wasnt right away
interesting
Copy code
INFO Attempting login via OAuth2
INFO OAuth2 login successful
INFO Starting new login timer
INFO Attempting login via OAuth2
INFO OAuth2 login successful
INFO Starting new login timer
INFO Attempting login via OAuth2
INFO OAuth2 login successful
INFO Starting new login timer
INFO Attempting login via OAuth2
INFO OAuth2 login successful
INFO Starting new login timer
INFO Attempting login via OAuth2
INFO OAuth2 login successful
INFO Starting new login timer
INFO Attempting login via OAuth2
INFO OAuth2 login successful
INFO Starting new login timer
so it went into that loop and then it got kicked out of the container prompt
back to the host
so its possible that the container is getting restarted
the docker ps still shows it as being up for 2 days, the mystery deepens
I think what might be happening is that the proc 1 for the container is not dying but the subprocs are getting restarted
I'll check the syslog next
hmm, I think this particular issue might have to do with docker running on apple silicon
Copy code
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Mar31 ?        00:00:08 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/meltano ui
root        23     1  0 Mar31 ?        00:02:21 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/gunicorn --config python:meltano.api.wsgi --pid /projects/.meltano/run/g
root       426     1  0 Mar31 ?        00:00:40 [tap-salesforce] <defunct>
root       438     1  0 Mar31 ?        00:00:55 /usr/bin/qemu-x86_64 /projects/.meltano/extractors/tap-salesforce/venv/bin/python /projects/.meltano/extractors/tap-salesforce/ven
root       498     1  0 Mar31 ?        00:00:26 [tap-salesforce] <defunct>
root       527     1  0 Mar31 ?        00:00:06 [tap-salesforce] <defunct>
root       537     1  0 Mar31 ?        00:00:56 /usr/bin/qemu-x86_64 /projects/.meltano/extractors/tap-salesforce/venv/bin/python /projects/.meltano/extractors/tap-salesforce/ven
root       675     0  0 Mar31 pts/0    00:00:07 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/meltano --log-level=debug select tap-salesforce --list --all
root       695   675  0 Mar31 pts/0    00:00:54 /usr/bin/qemu-x86_64 /projects/.meltano/extractors/tap-salesforce/venv/bin/python /projects/.meltano/extractors/tap-salesforce/ven
root      1108     0  0 Mar31 pts/1    00:00:09 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/meltano --log-level=debug select tap-salesforce --list --all
root      1127  1108  0 Mar31 pts/1    00:00:47 /usr/bin/qemu-x86_64 /projects/.meltano/extractors/tap-salesforce/venv/bin/python /projects/.meltano/extractors/tap-salesforce/ven
root      1337    23  0 03:53 ?        00:00:06 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/gunicorn --config python:meltano.api.wsgi --pid /projects/.meltano/run/g
root      1339    23  0 03:53 ?        00:00:06 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/gunicorn --config python:meltano.api.wsgi --pid /projects/.meltano/run/g
root      1341    23  0 03:53 ?        00:00:06 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/gunicorn --config python:meltano.api.wsgi --pid /projects/.meltano/run/g
root      1343    23  0 03:53 ?        00:00:06 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/gunicorn --config python:meltano.api.wsgi --pid /projects/.meltano/run/g
root      1573     1  0 16:57 ?        00:00:29 [tap-salesforce] <defunct>
root      1618     0  0 18:52 pts/2    00:00:00 /usr/bin/qemu-x86_64 /bin/bash
root      1656  1618  0 18:53 pts/2    00:00:07 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/meltano --log-level=debug invoke tap-salesforce --discover
root      1671  1656  0 18:53 pts/2    00:00:33 /usr/bin/qemu-x86_64 /projects/.meltano/extractors/tap-salesforce/venv/bin/python /projects/.meltano/extractors/tap-salesforce/ven
root      1769     0  0 21:22 pts/3    00:00:00 /usr/bin/qemu-x86_64 /bin/bash
root      1777  1769  5 21:22 pts/3    00:00:07 /usr/bin/qemu-x86_64 /usr/local/bin/python /usr/local/bin/meltano --log-level=debug select tap-salesforce --list --all
root      1792  1777 16 21:23 pts/3    00:00:22 /usr/bin/qemu-x86_64 /projects/.meltano/extractors/tap-salesforce/venv/bin/python /projects/.meltano/extractors/tap-salesforce/ven
root      1802     0  0 21:25 pts/4    00:00:00 /usr/bin/qemu-x86_64 /bin/bash
root      1812  1802  0 Mar30 ?        00:00:00 /bin/ps -ef
there are a bunch of defunct processes
gonna refresh the container and try again
have not made much progress, switching to an intel based docker to see if that does better. I might spend some time seeing about creating an arm64 version of the docker container.
d
@rohit_amarnath Looks like @dan_ladd ran into the same issue and submitted a fix: https://meltano.slack.com/archives/C013EKWA2Q1/p1617377257209100?thread_ts=1617145725.168100&amp;cid=C013EKWA2Q1
d
Ah nice, good timing!
r
superb!
gonna probably have to look up how to use that particular variant...
d
The fix I made is for
Copy code
<https://gitlab.com/meltano/tap-salesforce.git>
which seems to be the same variant you are already using
d
@rohit_amarnath While I review the MR, you can point Meltano directly at the fork: http://meltano.com/docs/plugin-management.html#using-a-custom-fork-of-a-plugin
r
ah good to know
thanks, let me try that
yay! I see dead people... I mean salesforce objects
d
@dan_ladd @rohit_amarnath I've merged the MR, so you should be able to change the 
pip_url
back to point at the main repo and get the latest version by running 
meltano install extractor tap-salesforce
!
r
sweet!
d
I never wanted this 🧵 to end, and luckily it turns out that MR didn't fix everything! That MR still wasn't working when the timer thread executed the login() call back (If the job takes >15 minutes). This does https://gitlab.com/meltano/tap-salesforce/-/merge_requests/12
t
@dan_ladd I’ve assigned to Douwe for a review. Thanks for submitting it!
15 Views
Open in Slack
PreviousNext
Powered by