Luis
Gonzalez

The Incident

In December 2025, the call center telephony sync system began generating incomplete data. By January 2026 it had stopped entirely. No alert had fired. No error appeared in the logs. The failure was silent by nature — a public IP change by the infrastructure team, unnotified, had severed the connection to the data source.

Investigation required coordinating with the telephony provider and the NOC team to trace a change that had happened weeks earlier. Once found, the scope became clear: ~50,000 audio recordings and 45 days of CSV reports needed to be recovered from scratch.

The Constraints

The provider's portal had the data — but no bulk download API. Each recording was accessible only via individual button click. The CSV reports were available as master files covering multiple months, requiring segmentation into daily files matching the exact naming format the Odoo sync module expected.

Additional complication: downloaded audio files carried the download date as mtime, not the original call date — and the Odoo sync module used st_mtime to organize files. Uploading them directly would place all 50,000 recordings on a single incorrect date.

The Problem

Fiberlux's custom Odoo module synced telephony data (call recordings, transcripts, quality reports) from Five9's SFTP server into the ERP. The original implementation was fully synchronous — during large data loads, it blocked Odoo's worker processes company-wide, freezing CRM and invoicing operations simultaneously.

Additional issues: data inconsistencies between Five9 and Odoo, growing storage costs from unmanaged file accumulation (~1M files since 2023), and fragile SFTP connectivity with no retry logic.

Architectural Solution

• Decoupled Threading: Migrated SFTP business logic to independent Python threads — achieving zero perceived latency for end users during mass synchronizations.
• Concurrency Control: Indexed boolean flags in PostgreSQL manage thread state and prevent race conditions across concurrent sync workers.
• SQL Optimization: B-Tree indexes on Many2one foreign keys + PostgreSQL views reduced query cost on 40k+ record tables for high-performance reporting.
• Batch Sanitization: Configurable days_to_sanitize with batch processing — auto-purges stale files on schedule, achieving 30% storage reduction.
• Resilient SFTP Client: Re-engineered using Fabric (replacing Paramiko) with hierarchical exception handling and automatic connection retry — handles network instability without operator intervention.
• Memory-Efficient Batch Governor: Configurable batch-size controller terminates remote scanning immediately upon reaching limit, preventing OOM during massive historical migrations.

The Problem

Odoo's standard security model restricts CRM and Sales document ownership to a single Salesperson field. At Fiberlux, multiple executives — Postventa, Fidelización, and others — needed to operate on the same customer account simultaneously.

The result: critical AccessError blocks on every cross-team operation, invoicing bottlenecks, and manual admin intervention required every 2–4 hours.

Architectural Solution

• Dynamic Security Bypass: Re-architected base rules using dot-notation relational paths, enabling safe CRUD for secondary executives without forking Odoo core.
• Context-Aware Approval Dispatch: Dispatcher inside create_level_ids inspects the operating uid and routes approvals to the correct team hierarchy.
• ORM Integrity Fix: Resolved unlink AccessError by bridging: order_id.partner_id.linked_executive_ids.user_id — forcing an implicit JOIN at query time.
• Auto-follower Integration: EVs wired into Odoo's messaging engine as automatic Followers — full lifecycle visibility without manual subscriptions.

The Problem

Fiberlux's invoicing workflow ran entirely inside Odoo — generating a single electronic invoice took ~2 minutes, with no async support. During billing peaks, the process saturated Odoo workers and blocked the entire ERP.

Solution

• 10 parallel async workers — 50 invoices with QR codes in ~35 seconds.
• Async/Sync dual mode — automatic synchronous fallback on API instability.
• Full validation engine — detracciones, exportaciones, IGV, USD/PEN per SUNAT normativa.
• Exponential backoff retry — every state transition recorded atomically for compliance.
• 100% test coverage before production deployment.

The Challenge

Fiberlux operates a critical production ERP on Odoo v13 managing mass invoicing, CRM, telephony integration, and customer contracts — all heavily customized. A v17 upgrade proved infeasible; deprecated APIs, large data volume, and billing continuity requirements drove the decision toward a full Django rewrite.

Phased Extraction Strategy

• Phase 1 — Stabilize v13: Resolved production deadlocks via Odoo worker tuning, memory limits, and PostgreSQL connection pooling. Deployed "Testodoo" environment for safe mass validation.
• Phase 2 — Flat-table Bridge: Migrated first 5 modules using intermediate flat tables — decoupling business logic from Odoo ORM while maintaining data continuity.
• Phase 3 — Extract to Django: Invoicing engine, Five9 sync, and EV governance fully migrated to standalone Django services with clean REST API boundaries.
• Phase 4 — Containerization: Dockerizing v13 production base with environment parity across dev, staging, and production.

The Problem

Critical Odoo and Django workflows exhibited unexplained latency under production load. Without systematic profiling, bottleneck identification was guesswork — developers were optimizing the wrong paths while true hotspots remained undetected.

Methodology

• cProfile + SnakeViz — full call-stack timing; flame graphs to identify dominant call chains.
• N+1 detection — resolved with select_related() and prefetch_related(), collapsing hundreds of queries into single optimized calls.
• EXPLAIN ANALYZE — identified sequential scans; created B-Tree composite indexes on FK and date range columns.
• O(n²) → O(n) — replaced nested loops with set-based lookups and pre-computed dicts outside iteration.