adobe-apiplatform/user-sync.py

Unhandled exception when running --adobe-only-user-action write-file

srtucker opened this issue · 8 comments

srtucker commented

Description
When using with the --adobe-only-user-action write-file option, an unhandled exception occurs after writing the CSV and the process completes with an exit code of zero.

Steps to reproduce

  • Relevant config options
    • All default config options except for group mappings, UMAPI credentials, and LDAP credentials.
  • Command-line options used
    ./user-sync --test-mode --adobe-only-user-action write-file users-to-cleanup.csv --no-update-user-info --exclude-unmapped-users
  • Specific details around identity source, group mapping, etc.
    • Identity source is AD, group mapping is configured but I believe it is unused in this scenario.

Expected behavior
An unhandled exception is not raised. (If one is, the program should exit with a non-zero exit code so it can be easily detected without parsing the output).

Screenshots
The following stack trace is produced.

ERROR main - Unhandled exception
Traceback (most recent call last):
  File "/user_sync/app.py", line 441, in run_sync
    begin_work(config_loader)
  File "/user_sync/app.py", line 390, in begin_work_umapi
    rule_processor.run(directory_groups, directory_connector, umapi_connectors)
  File "/user_sync/engine/umapi.py", line 198, in run
    primary_commands, secondary_command_lists = self.process_strays(primary_commands,
TypeError: cannot unpack non-iterable NoneType object

Environment

  • UST version: 2.7.5
  • OS type and version: Amazon Linux 2
  • Any other relevant info: None

Potential solution
In user_sync/engine/umapi.py after line 640 (at the end of process_strays method) I believe the following line should be added to resolve the issue:

        return primary_commands, secondary_command_lists
adorton-adobe commented

I will take a look.

  • 👍1
adorton-adobe commented

The fix is here - https://github.com/adobe-apiplatform/user-sync.py/tree/fix/write-adobe-only

I'm not sure how long it will be before the next release but should not be too long.

srtucker commented

Perfect, thank you!

srtucker commented

Sorry, there id one more thing I found when troubleshooting this error that this fix does not resolve. When an error is thrown, it is caught by the tool and logged, but the program still exits with a return code of zero. This make it is much harder to programmatically determine an error occurred.

adorton-adobe commented

That is a good idea, but not really a blocker for this bug. I'm created a feature request for it at #803.

srtucker commented

I agree that it is a separate item. Thanks for adding the feature request and implementing it.

srtucker commented

@adorton-adobe Do you have an estimate on when the next release will be? Thanks

adorton-adobe commented

I don't. The fix is merged however if you want to make your own build temporarily. Just build v2 the main dev branch. Instructions for building are in the readme.