ali
/
jey_wizard
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Trace whether amas_api worker module has the parallel import code 

Reported symptom: ƏMAS employees imported via the wizard appear to
trickle in one-by-one (old sequential _process_bulk_employees_import),
while invoice_az's in-app "Load from ƏMAS" button finishes the same
volume in seconds via the new ThreadPoolExecutor Phase A + sequential
Phase B path.

The wizard and the in-app flow both call invoice_az.amas_api.
import_bulk_employees, which frappe.enqueue's the work to a Frappe
RQ worker. Same code on disk, same enqueue, same worker queue — so
there's no place left where the wizard could pick a different code
path. The remaining plausible explanations are out-of-band:
  - parallel changes never committed/pushed to the test machine
  - workers running with stale imports because only `bench restart
    web` (or only the supervisor web group) ran, not the workers

Add `parallel_module_available` (truthy iff invoice_az.amas_api
exposes the BULK_IMPORT_PARALLELISM constant added in the parallel
refactor) and the constant value itself to the existing
"Jey Wizard trace: amas enqueued" Error Log entry. After the next
finalize on the test machine, that line will say either
  parallel_module_available: true,  bulk_parallelism: 10
or
  parallel_module_available: false, bulk_parallelism: null
which is enough to tell the source-of-truth from the in-process
state without rerunning anything.
This commit is contained in:
Ali 2026-05-01 15:58:54 +00:00
parent 8fe891d898
commit 29f277a7bf
3 changed files with 15 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
jey_wizard/__init__.py
View File

@ -1 +1 @@
__version__ = "0.1.20"
__version__ = "0.1.21"

13
jey_wizard/etaxes.py
View File

@ -1018,8 +1018,19 @@ def _materialize_amas_employees(company_name):
return
try:
from invoice_az import amas_api as _amas_api
from invoice_az.amas_api import import_bulk_employees
# Diagnostic flag: BULK_IMPORT_PARALLELISM only exists in the post-
# refactor version that runs Phase A (ThreadPool fetch) + Phase B
# (sequential DB writes). If this is False on the test machine, the
# pulled / cached amas_api.py is still the old sequential version
# and the wizard's import will be slow even though invoice_az's
# in-app "Load from ƏMAS" appears fast (different module instance,
# different process state).
parallel_module_available = hasattr(_amas_api, "BULK_IMPORT_PARALLELISM")
bulk_parallelism = getattr(_amas_api, "BULK_IMPORT_PARALLELISM", None)
result = import_bulk_employees(
asan_login_name=asan_login,
employees_data=json.dumps(employees, ensure_ascii=False),
@ -1057,6 +1068,8 @@ def _materialize_amas_employees(company_name):
"asan_login": asan_login,
"employees": len(employees),
"create_designation": create_designation,
"parallel_module_available": parallel_module_available,
"bulk_parallelism": bulk_parallelism,
"result": result if isinstance(result, dict) else {"raw": str(result)},
}, ensure_ascii=False, indent=2),
"Jey Wizard trace: amas enqueued",

2
jey_wizard/public/js/jey_setup.js
View File

@ -10,7 +10,7 @@ frappe.provide("jey_wizard");
// Bump this string in every commit that changes wizard code. Displayed in the badge so
// we can tell at a glance which version is actually running on a given machine. Kept in
// sync with __version__ in jey_wizard/__init__.py.
const JEY_WIZARD_VERSION = "0.1.20";
const JEY_WIZARD_VERSION = "0.1.21";
// Wipe Frappe + ERPNext default slides so their `before_load`/`after_load` listeners
// don't try to mutate a wizard that isn't slide-based anymore.