Skip to main content

Velox Technical Debt

Summary​

This document is part of the internal Velox Product Knowledge Base (PKB). It records technical debt and stability risks discovered from static review of the velox repository.

The purpose is to give future developers, AI agents, and technical writers a stable reference for known codebase risks. It is not a fix plan, and it does not change source code.

This document is based primarily on Technical Review TODO, then cross-checked against source locations for large classes, duplicated code, obsolete or inactive code, runtime risks, performance concerns, architectural concerns, thread safety concerns, and 32-bit versus 64-bit concerns. Every item is ranked as High, Medium, or Low.

Source Basis​

Primary source locations and documents used:

  • TODO.md - detailed static review findings and risk notes in this PKB folder.
  • Classes\vxModule.pas - module persistence, logging, relation handling, template loading, and global module load locking.
  • Classes\vxActionMan.pas - Flow/Action model and execution orchestration.
  • Classes\Service\vxActionThread.pas - worker threads for manual, scheduled, monitor, transport, and REST action execution.
  • Classes\Service\vxManagerREST.pas - REST endpoint registry, API request dispatch, timeout handling, and REST action synchronization.
  • Classes\Service\vxManagerExecution.pas - service execution item lifecycle and forceful thread termination.
  • Classes\vxExecutionMonitor.pas - Designer/runtime execution monitor and forceful termination path.
  • Classes\vxActionPool.pas, Classes\vxSQLConPool.pas - pooled action and SQL connection lookup behaviour.
  • Classes\GUI\vxDBUpdate.pas, Classes\GUI\vxDBUpdateVersion.pas - database version dispatcher and version implementations.
  • Classes\vxCon.pas, Classes\dmSystemDB.pas - system connection, config/log/data connection access, and log database abstraction.
  • Classes\vxConfigTemplate.pas - configuration template save/export logic.
  • Classes\Tools\vxShell.pas - Windows session helper declaration.
  • Classes\Tools\vxZip.pas - low-level ZIP implementation.
  • Classes\Transports\vxTransportIBMMQ.pas - IBM MQ transport integration.
  • Forms\frmCodeLibrary.pas, Classes\GUI\vxCodeExplorer.pas - Code Library tree node storage and navigation.
  • Forms\frmSetupActions.pas - active Flow setup form.
  • VeloxService\classMain.pas, VeloxAPIService\classMain.pas - duplicated service lifecycle and IPC infrastructure.
  • Active first-party line-count scan of Classes\, Forms\, VeloxService\, VeloxAPIService\, and VeloxTest\.

Important Classes, Forms, and Services​

Important classes:

  • TvxModule - base module, persistence, relations, templates, and logs.
  • TvxActionMan - Flow/Action configuration and runtime execution.
  • TvxRESTManager, TvxRESTItem, TRESTActionThread - REST endpoint synchronization and API Flow execution.
  • TvxExecutionItem, TvxExecutionMonitor - runtime execution status and cancellation/termination.
  • TvxActionPool, TvxSQLConPool - pooled runtime resources.
  • TvxConfigTemplate - module/template export and save ordering.
  • TvxConnection, TvxSystemDB - config/log/data connection access.
  • TvxTransportIBMMQ - IBM MQ transport boundary.

Important forms:

  • TSetupActions in Forms\frmSetupActions.pas.
  • Forms\LinkedAction\frmSetupActions.pas is ignored by repository guidance as trial/test/backup code.
  • TCodeLibrary in Forms\frmCodeLibrary.pas.
  • TMain in Forms\frmMain.pas.
  • Log and transport log forms under Forms\frmLogs.pas, Forms\frmManageLogs.pas, and Forms\frmManageTransportLogs.pas.

Important services:

  • TVeloxWorker in VeloxService\classMain.pas.
  • TVeloxAPIWorker in VeloxAPIService\classMain.pas.
  • Service managers under Classes\Service\.

Related configuration:

  • C:\ProgramData\Velox\Config\Connections.json - active/test config/log/data database connection selection.
  • TvxSetup in Classes\vxSetup.pas - service, API, logging, transport, and runtime flags.
  • VX_ACTION, VX_API, VX_LOG, VX_LOG_TRANSPORT, and related Velox configuration/logging tables.
  • Database version updates in Classes\GUI\vxDBUpdate*.pas.

Static Review Limits​

  • This is a static source review.
  • No Delphi build was run for this document.
  • No runtime tests, service tests, API tests, Win32 tests, Win64 tests, IBM MQ tests, or ZIP integration tests were run for this document.
  • Vendor code was not treated as normal refactoring scope.
  • Where behaviour is unclear from source, the item says so explicitly.

Risk Register​

High: REST API timeout can free an action while it is still executing​

Category: Thread safety, runtime stability, API execution.

Source locations:

  • Classes\Service\vxManagerREST.pas:134 - TvxRESTItem.ExecuteGET.
  • Classes\Service\vxManagerREST.pas:194 - TvxRESTItem.ExecutePOST.
  • Classes\Service\vxActionThread.pas:626 - TRESTActionThread.Execute.

Evidence: GET and POST REST execution create a TRESTActionThread, wait up to FIVE_MINS_MILLI, and then use the thread action after the wait. On timeout, the finally block can call FreeAndNil(lThread.Action) when the worker thread may still be running. TRESTActionThread.Execute later enters FAction.Execute, so the action lifetime can overlap the timeout cleanup. lAction is declared before the try block in both methods and is used in Assigned(lAction) checks; the reviewed code does not initialize it before the wait path.

Impact: Use-after-free, access violations, corrupt Flow state, leaked or invalid database connections, incorrect API response state, and difficult-to-reproduce service crashes.

Suggested direction: Replace timeout cleanup with cooperative cancellation. Make action ownership explicit and single-owner. Initialize locals defensively. Do not free an action until the worker thread has actually stopped.

Related documentation: Architecture, Domain Model, Technical Review TODO.

High: REST endpoint dictionary is not consistently thread-safe​

Category: Thread safety, API routing, runtime stability.

Source locations:

  • Classes\Service\vxManagerREST.pas:42 - FEndpoints: TDictionary<string,TvxRESTItem>.
  • Classes\Service\vxManagerREST.pas:406 and Classes\Service\vxManagerREST.pas:431 - endpoint lookup/add during sync.
  • Classes\Service\vxManagerREST.pas:561 - request endpoint execution.
  • Classes\Service\vxManagerREST.pas:607 - FreeOldRESTItems.
  • Classes\Service\vxManagerREST.pas:611 and Classes\Service\vxManagerREST.pas:618 - dictionary enumeration and removal.

Evidence: Request lookup uses a lock around TryGetValue, but sync/removal paths are not consistently protected by the same lock. FreeOldRESTItems iterates FEndpoints and removes from FEndpoints inside the same enumeration.

Impact: Collection-modified exceptions, race conditions while API requests are active, endpoint loss, incorrect routing, or crashes during REST sync.

Suggested direction: Use one lock for every read/write of FEndpoints. Avoid mutating a dictionary while enumerating it; collect removals first, then remove after enumeration. Verify behaviour under concurrent requests and service sync.

Related documentation: Architecture, Technical Review TODO.

High: Flow/action cancellation uses TerminateThread​

Category: Thread safety, service shutdown, runtime stability.

Source locations:

  • Classes\Service\vxManagerExecution.pas:472 and Classes\Service\vxManagerExecution.pas:477 - TvxExecutionItem.ForcefullyTerminate.
  • Classes\vxExecutionMonitor.pas:117 and Classes\vxExecutionMonitor.pas:130 - TvxExecutionMonitor.ForcefullyTerminateThreads.
  • Forms\frmMain.pas:1686 to Forms\frmMain.pas:1688 - Designer shutdown termination sequence.
  • Forms\frmLogs.pas:510 - log UI termination path.

Evidence: Current code calls TerminateThread in execution and monitor paths. Source comments warn that forceful termination should be used with care.

Impact: Locks may remain held, COM/OLE state may not unwind, database transactions or connections may be left invalid, object destructors may not run, and module/log/transport state can be partially updated. This is especially important because VeloxService stability is a key product concern.

Suggested direction: Move toward cooperative cancellation. Ensure long-running actions, transports, scripts, database operations, and file operations check cancellation state. Keep forceful termination only as an explicit last-resort process shutdown fallback if it cannot be removed immediately.

Related documentation: Developer Guide, Technical Review TODO.

High: Core runtime classes and methods are very large and high complexity​

Category: Large classes, architectural concern, maintainability.

Source locations:

  • Classes\vxModule.pas - about 4,901 lines; TvxModule starts at Classes\vxModule.pas:86.
  • Classes\vxActionMan.pas - about 4,097 lines; TvxActionMan starts at Classes\vxActionMan.pas:299.
  • Classes\Service\vxManagerREST.pas - REST manager and REST item execution.
  • VeloxService\classMain.pas - TVeloxWorker.ServiceExecute at VeloxService\classMain.pas:178 and IPC handler at VeloxService\classMain.pas:449.
  • VeloxAPIService\classMain.pas - TVeloxAPIWorker.ServiceExecute at VeloxAPIService\classMain.pas:193.
  • Forms\frmSetupActions.pas - about 2,827 lines; TSetupActions.RefreshActionDetails starts at Forms\frmSetupActions.pas:980.

Evidence: Static line-count scan shows the largest active first-party units are concentrated in module persistence, Flow execution, Flow setup UI, logging/UI, and service/runtime orchestration. Approximate method spans include TvxActionMan.ExecuteOnce at about 218 lines, main TSetupActions.RefreshActionDetails at about 162 lines, and TvxConfigTemplate.SaveAllModules at about 105 lines. Ignored trial/test/backup folders are not counted as active debt.

Impact: Changes are hard to reason about and can accidentally affect persistence, logging, threading, API behaviour, service lifecycle, or Designer state. Regression risk is high even for small edits.

Suggested direction: Avoid broad rewrites. When touching these areas, make narrow, source-grounded changes. Add focused regression coverage around the specific behaviour. Extract shared behaviour only when a stable ownership boundary is clear.

Related documentation: Knowledge Map, Architecture, Technical Review TODO.

High: Code Library stores object pointers through 32-bit integers​

Category: 32-bit versus 64-bit, runtime stability, UI navigation.

Source locations:

  • Forms\frmCodeLibrary.pas:461 - TCodeLibrary.mdViewerHotSpotClick.
  • Forms\frmCodeLibrary.pas:478 - pointer read using Fields[Ord(cfNodePointer)].AsInteger.
  • Forms\frmCodeLibrary.pas:481 - integer cast back to TvxCodeNode.
  • Classes\GUI\vxCodeExplorer.pas:16 - TvxCodeNode.

Evidence: lPointer is declared as integer, populated from AsInteger, and cast to TvxCodeNode. On 64-bit builds, object references are pointer-sized and can exceed 32 bits.

Impact: 64-bit pointer truncation can cause access violations, incorrect tree navigation, or memory corruption when Code Library hot spots activate existing tree nodes.

Suggested direction: Do not store object references through Integer or AsInteger. Prefer a stable lookup key or actual object ownership/reference model. If a pointer-sized cast is unavoidable, use NativeInt/NativeUInt and 64-bit tests.

Related documentation: Developer Guide, Technical Review TODO.

Medium: Database version 311 dispatches version 310​

Category: Potential bug, database upgrade risk.

Source locations:

  • Classes\GUI\vxDBUpdate.pas:243 - version 310 dispatches TVxDBUpdateVersion310.
  • Classes\GUI\vxDBUpdate.pas:244 - version 311 also dispatches TVxDBUpdateVersion310.
  • Classes\GUI\vxDBUpdateVersion.pas:199 - TVxDBUpdateVersion311 class exists.
  • Classes\GUI\vxDBUpdateVersion.pas:1534 - TVxDBUpdateVersion311.Update exists.

Evidence: Dispatcher maps both 310 and 311 to TVxDBUpdateVersion310, even though a version 311 class exists.

Impact: If database version 311 is active or intended to be active, its update may never run. Customers could experience schema drift or missing upgrade work.

Suggested direction: Confirm whether 311 should dispatch TVxDBUpdateVersion311. If yes, correct the dispatcher and test upgrade sequencing.

Related configuration: SQL Server 2025 Velox configuration database; database update classes.

Medium: TvxConnection.GetConfigNum is empty​

Category: Potential bug, configuration access.

Source locations:

  • Classes\vxCon.pas:55 - GetConfigNum declaration.
  • Classes\vxCon.pas:366 - ConfigNumThreadSafe returns FConfigNum.
  • Classes\vxCon.pas:452 - TvxConnection.GetConfigNum starts and has no visible return body.

Evidence: The thread-safe accessor returns FConfigNum, but the non-thread-safe accessor body is empty in the reviewed source.

Impact: Calls through the ConfigNum property can return an undefined/default value or inconsistent value compared with ConfigNumThreadSafe.

Suggested direction: Confirm intended behaviour and implement an explicit return if the property is still used.

Related configuration: Connections.json and config/log/data database selection.

Medium: ProcessIdToSessionId declaration is not 64-bit safe​

Category: 32-bit versus 64-bit, Windows API interop.

Source locations:

  • Classes\Tools\vxShell.pas:50 - ProcessIdToSessionId(dwProcessId: DWORD; pSessionId: DWORD): BOOL.
  • Classes\Tools\vxShell.pas:104 - external declaration.
  • Classes\Tools\vxShell.pas:108 - call with DWORD(@sessionId).

Evidence: The WinAPI expects a pointer to a DWORD for the second parameter. The code casts an address to DWORD, which is 32-bit storage.

Impact: On 64-bit builds, the session id pointer can be truncated. Service/user-session helper paths may fail intermittently or corrupt memory.

Suggested direction: Use a pointer-width-safe declaration such as PDWORD or a var parameter. Test the shell/session helper paths in Win32 and Win64.

Related services: VeloxService and any helper paths that launch or inspect user sessions.

Medium: Config template save result can hide earlier failures​

Category: Potential bug, import/export reliability.

Source locations:

  • Classes\vxConfigTemplate.pas:592 - TvxConfigTemplate.SaveAllModules.
  • Classes\vxConfigTemplate.pas:603 to Classes\vxConfigTemplate.pas:689 - repeated FResult := Save... assignments.
  • Classes\vxConfigTemplate.pas:692 - Result := FResult.

Evidence: Save operations overwrite FResult repeatedly. A failed earlier save can be replaced by a later successful result.

Impact: Template/config export can report success when some module saves failed, causing incomplete templates or misleading deployment/export results.

Suggested direction: Accumulate failures and preserve step-level failure context. Treat this as compatibility-sensitive because templates are part of configuration movement.

Related UI: Forms\frmConfigTemplateImporter.pas.

Medium: TvxRESTManager.DisableAction is an active stub​

Category: Obsolete/stub code, service/API lifecycle risk.

Source locations:

  • Classes\Service\vxManagerREST.pas:705 - TvxRESTManager.DisableAction.

Evidence: The function body is mostly commented out and does not have a clear active implementation or active Result assignment in the reviewed source.

Impact: If called through service IPC or future API service sync paths, disable behaviour may be a no-op and the boolean result may be undefined.

Suggested direction: Confirm all call paths. Either implement the method, return a deliberate explicit value with logging, or remove unsupported call paths.

Related services: VeloxAPIService REST synchronization and Designer service management.

Medium: VeloxService and VeloxAPIService duplicate service infrastructure​

Category: Duplicated code, architectural concern.

Source locations:

  • VeloxService\classMain.pas:18 - TVeloxWorker.
  • VeloxAPIService\classMain.pas:19 - TVeloxAPIWorker.
  • VeloxService\classMain.pas:58 and VeloxAPIService\classMain.pas:55 - similar service helper methods.
  • VeloxService\classMain.pas:449 and VeloxAPIService\classMain.pas:584 - IPC request handlers.

Evidence: Both services implement similar lifecycle, install/uninstall, user/password, config key, test mode, display-name, IPC, and shutdown logic.

Impact: Fixes can be made in one service and missed in the other. API service-specific changes such as SSL/port handling may diverge from shared service behaviour.

Suggested direction: Keep fixes deliberately synchronized. Consider a shared service helper layer only when there is a clear boundary and tests around service lifecycle.

Related services: TVeloxWorker, TVeloxAPIWorker.

Medium: ZIP and IBM MQ integration need 64-bit and Unicode regression coverage​

Category: 32-bit versus 64-bit, external ABI, transport reliability, performance/stability.

Source locations:

  • Classes\Tools\vxZip.pas - about 4,113 lines of low-level ZIP implementation.
  • Classes\Tools\vxZip.pas:665 - CompressEx.
  • Classes\Tools\vxZip.pas:1911 - UncompressEx.
  • Classes\Transports\vxTransportIBMMQ.pas - IBM MQ transport integration.

Evidence: vxZip.pas is large, low-level, historically patched code with pointer arithmetic and ANSI/PAnsiChar style boundaries. IBM MQ transport code uses vendor APIs and fixed-size buffers/structures.

Impact: ABI, encoding, buffer-length, and pointer-size issues can affect production file transport and MQ delivery. Static review cannot prove whether all supported client bitness/version combinations are safe.

Suggested direction: Add focused Win32/Win64 regression coverage for ZIP operations, large archives, and Unicode filenames. Test IBM MQ send/receive with supported client libraries and message sizes.

Related services: Transport managers and Flow execution.

Low: Ignored action setup fork remains in the repository​

Category: Repository hygiene.

Source locations:

  • Forms\frmSetupActions.pas:25 - main TSetupActions.
  • Forms\frmSetupActions.pas:980 - main RefreshActionDetails.
  • Forms\LinkedAction\frmSetupActions.pas - ignored by repository guidance.

Evidence: Forms\LinkedAction is documented in AGENTS.md as trial/test/backup code that can be ignored.

Impact: Repository search results can still find inactive code, but active Flow setup changes should be made in Forms\frmSetupActions.pas.

Suggested direction: Ignore Forms\LinkedAction unless a task explicitly targets trial/test/backup code.

Related UI: Active Flow setup.

Medium: Action and SQL connection pools use list scans​

Category: Performance concern, service scalability.

Source locations:

  • Classes\vxActionPool.pas:28 - comment MAKE TDICTIONARY.
  • Classes\vxActionPool.pas:85 to Classes\vxActionPool.pas:108 - action pool lookup/scanning.
  • Classes\vxSQLConPool.pas:32 - comment MAKE TDICTIONARY.
  • Classes\vxSQLConPool.pas:91 and related methods - SQL connection pool lookup/scanning.

Evidence: Pool items use list-backed lookup and source comments already identify dictionary conversion as a possible improvement.

Impact: Under large action counts, high thread counts, or busy services, lookup time and lock duration can increase.

Suggested direction: Consider dictionary-backed lookup when identity keys are stable. Preserve current ownership, thread locking, pooling, and release semantics.

Related services: VeloxService, VeloxAPIService, action/connection pool runtime.

Medium: Module loading is globally serialized​

Category: Performance concern, architectural concern, thread safety.

Source locations:

  • Classes\vxModule.pas:1483 - LoadModuleTemplate.
  • Classes\vxModule.pas:1510 - LoadModule.
  • Classes\Tools\vxConfig.pas:44 - gModuleCritSect.
  • Classes\Tools\vxConfig.pas:101 - critical section creation.

Evidence: Module loading uses a global critical section. The existing code comments connect this to safe module loading and ReportBuilder thread-safety concerns.

Impact: The global lock may limit service/API throughput when many flows load modules concurrently. Long module load paths can block unrelated module loads.

Suggested direction: Treat the lock as intentional until the unsafe dependency is isolated. If performance becomes a problem, investigate narrower locking around the unsafe component rather than removing the lock globally.

Related services: Flow execution, REST request execution, service manager synchronization.

Medium: Log database separation is not implemented​

Category: Architectural concern, configuration/database concern.

Source locations:

  • Classes\vxCon.pas:571 to Classes\vxCon.pas:577 - TvxConnection.SQLL currently returns config connection.
  • Classes\dmSystemDB.pas:273 to Classes\dmSystemDB.pas:291 - TvxSystemDB.GetSQLL comments and inactive separate-log connection path.
  • Classes\GUI\vxDBUpdate.pas:68 and Classes\GUI\vxDBUpdate.pas:78 - log database version checks use SQLL.

Evidence: Comments state that log connections currently use active config connection until separate log database behaviour is tested/running.

Impact: Future separation of config and log databases will require careful audit of connection ownership, transactions, schema updates, and callers of SQLL, SQLC, ActiveConfig, and ActiveLog.

Suggested direction: Keep log access behind log-specific abstractions. Do not replace SQLL with config access directly. When separation is implemented, test config/log split thoroughly.

Related configuration: Connections.json, config/log database keys, SQL Server 2025 database configuration.

Low: Large utility routines are difficult to change safely​

Category: Large methods, regression risk.

Source locations:

  • Classes\Tools\vxZip.pas - ZIP routines and wrappers.
  • Classes\Tools\vxDateTools.pas:321 - vxStringtoDateTime.
  • Classes\Tools\vxDateTools.pas:571 - vxStringtoDateTimeValid.
  • Classes\vxAPI.pas:262 - TvxAPI.CreateOpenAPISchema.

Evidence: These routines are sizeable and encode format-specific behaviour. They are not necessarily defective, but they are risky to change without targeted tests.

Impact: Changes can create regressions in ZIP handling, date parsing, or OpenAPI schema generation.

Suggested direction: Add focused tests before changing behaviour. Avoid style-only refactors in these routines.

Related documentation: Domain Model, Architecture.

Low: Probable inactive or experimental code exists in backup/new folders​

Category: Obsolete code, repository hygiene.

Source locations:

  • _BACKUP\.
  • Classes\_NEW\.

Evidence: AGENTS.md documents _BACKUP, Classes\_NEW, Forms\Action, and Forms\LinkedAction as trial, test, or backup code that can be ignored.

Impact: Future maintainers can waste time reviewing inactive code or accidentally copy old/experimental patterns into production code.

Suggested direction: Leave untouched unless a task explicitly targets ignored trial/test/backup code.

Related documentation: Developer Guide, AGENTS.md.

Low: Very large generated/imported units can distort code searches​

Category: Large files, repository hygiene.

Source locations:

  • Imports\MSHTML_TLB.pas - about 68,796 lines.
  • Imports\MSXML2_TLB.pas - about 4,881 lines.
  • Imports\MSMQ_TLB.pas - about 3,503 lines.
  • Imports\IBMMQ\MQI*.PAS - IBM MQ imported units.
  • Scripting\Source\Source that should not be compiled - just used to create imports\*.pas.

Evidence: Line-count scan shows imported/generated units dominate some size lists. Some scripting source paths explicitly say they should not be compiled and are used to create imports.

Impact: Search and static analysis results can be noisy. Large generated files should not be treated like normal refactoring targets.

Suggested direction: Exclude imported/generated folders when doing maintainability scans unless the task specifically targets those bindings. Keep dependency/import regeneration procedures documented if they become active work.

Related documentation: Developer Guide.

Low: Remaining pointer-width cleanup candidates should be reviewed opportunistically​

Category: 32-bit versus 64-bit, code clarity.

Source locations:

  • UI list/tree code that stores values in pointer-like properties such as TListItem.Data.
  • Classes\Tools\vxReportRTTI.pas contains integer casts for script/report RTTI value access.

Evidence: The TODO review notes some reviewed cases appear to store small integer indexes rather than object pointers. They are lower risk than the Code Library pointer round trip, but they can still be confusing in a mixed Win32/Win64 codebase.

Impact: Future changes may accidentally store real pointers through fixed-width integers, or maintainers may misread integer-as-pointer patterns.

Suggested direction: Prefer NativeInt/NativeUInt or typed references when pointer-sized values are intended. Leave safe small-integer fields alone unless touching related code.

Related documentation: Developer Guide.

Debt by Required Theme​

Large Classes and Methods​

Ranked items:

  • High: Core runtime classes and methods are very large and high complexity.
  • Low: Large utility routines are difficult to change safely.
  • Low: Very large generated/imported units can distort code searches.

Largest active first-party units from static scan:

  • Classes\vxModule.pas - about 4,901 lines.
  • Classes\Tools\vxZip.pas - about 4,113 lines.
  • Classes\vxActionMan.pas - about 4,097 lines.
  • Classes\GUI\vxTreeNodes.pas - about 3,645 lines.
  • Forms\frmSetupActions.pas - about 2,827 lines.
  • Classes\vxMap.pas - about 2,747 lines.
  • Classes\vxScripter.pas - about 2,643 lines.
  • Forms\frmMain.pas - about 2,172 lines.
  • Forms\frmLogs.pas - about 2,098 lines.
  • Classes\vxDataDef.pas - about 2,043 lines.

Duplicated Code​

Ranked items:

  • Medium: VeloxService and VeloxAPIService duplicate service infrastructure.
  • Low: Ignored action setup fork remains in the repository.
  • Medium: REST GET/POST execution paths in Classes\Service\vxManagerREST.pas are similar and share the same timeout/lifetime concerns.

Obsolete, Stub, or Inactive Code​

Ranked items:

  • Medium: TvxRESTManager.DisableAction is an active stub.
  • Low: Ignored trial/test/backup folders remain in the repository.
  • Low: Very large generated/imported units can distort code searches.

Enum values marked Old/OLD in Classes\Tools\vxTypes.pas should be treated as compatibility-sensitive until traced. They are not listed as defects by themselves.

Risks and Potential Bugs​

Ranked items:

  • High: REST API timeout can free an action while it is still executing.
  • High: REST endpoint dictionary is not consistently thread-safe.
  • High: Flow/action cancellation uses TerminateThread.
  • High: Code Library stores object pointers through 32-bit integers.
  • Medium: Database version 311 dispatches version 310.
  • Medium: TvxConnection.GetConfigNum is empty.
  • Medium: Config template save result can hide earlier failures.
  • Medium: TvxRESTManager.DisableAction is an active stub.

Performance Concerns​

Ranked items:

  • Medium: Action and SQL connection pools use list scans.
  • Medium: Module loading is globally serialized.
  • Medium: REST API execution waits synchronously up to FIVE_MINS_MILLI per request path before timeout handling.
  • Low: Large utility routines can become performance-sensitive if changed without focused tests.

Architectural Concerns​

Ranked items:

  • High: Core runtime classes and methods are very large and high complexity.
  • Medium: Log database separation is not implemented.
  • Medium: VeloxService and VeloxAPIService duplicate service infrastructure.
  • Medium: Module loading is globally serialized.
  • Medium: Action setup forms are forked.

Thread Safety Concerns​

Ranked items:

  • High: REST API timeout can free an action while it is still executing.
  • High: REST endpoint dictionary is not consistently thread-safe.
  • High: Flow/action cancellation uses TerminateThread.
  • Medium: Module loading is globally serialized.
  • Medium: Action and SQL connection pools should preserve existing locking if optimized.
  • Medium: Transport and REST code rely on thread-local or locally copied state; changes need service/API runtime tests.

32-bit Versus 64-bit Concerns​

Ranked items:

  • High: Code Library stores object pointers through 32-bit integers.
  • Medium: ProcessIdToSessionId declaration is not 64-bit safe.
  • Medium: ZIP and IBM MQ integration need 64-bit and Unicode regression coverage.
  • Low: Remaining pointer-width cleanup candidates should be reviewed opportunistically.

Stabilization Guidance​

Recommended ordering for future remediation:

  1. Address high-risk thread-safety and lifetime issues first, especially REST action timeout cleanup and endpoint dictionary locking.
  2. Remove direct 32-bit pointer truncation in Code Library before relying on 64-bit Designer Code Library workflows.
  3. Replace or constrain TerminateThread usage with cooperative cancellation where possible.
  4. Confirm and fix concrete medium-risk bugs such as database version 311 dispatch and GetConfigNum.
  5. Add regression coverage around service shutdown, REST request concurrency, Flow execution, import/export templates, and Win32/Win64 native boundary code before broader refactors.
  6. Only then consider structural cleanup for duplicated services/forms or pool lookup performance.

Open Questions​

  • Should database version 311 dispatch TVxDBUpdateVersion311 now, or is version 311 intentionally dormant?
  • Is TvxConnection.GetConfigNum unused, or should it return FConfigNum like ConfigNumThreadSafe?
  • Which code paths currently call TvxRESTManager.DisableAction in production?
  • What is the desired cooperative cancellation model for long-running actions, transports, scripts, reports, database operations, and file operations?
  • Is the Code Library expected to be fully supported in 64-bit Designer builds?
  • Which IBM MQ client versions and bitness combinations are supported in production?
  • What ZIP filename encodings and archive sizes must be supported for customer integrations?
  • What is the intended timeline for separating config and log databases?