Profiles·Public

tedious

semver>=18.0.0postconditions26functions13last verified2026-06-24coverage score100%

Postconditions: what we check

  • connect · connection-failure
    error
    WhenCannot connect (wrong credentials, server unreachable, etc.)
    ThrowsConnectionError event with details
    Required handlingCaller MUST handle 'error' event on Connection. Common error codes: - ESOCKET: Network/socket error - ELOGIN: Authentication failed - ETIMEOUT: Connection timeout Implement retry with exponential backoff for transient issues.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • execSql · syntax-error
    error
    WhenSQL syntax error
    ThrowsError event on Request with error.number indicating syntax error
    Required handlingCaller MUST handle 'error' event on Request. SQL Server error numbers: - 102, 156: Syntax errors - 207: Invalid column name - 208: Invalid object name (table not found) DO NOT retry - fix SQL syntax.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[2]
  • execSql · constraint-violation
    error
    WhenUnique constraint, foreign key, or NOT NULL violation
    ThrowsError event with error.number for constraint violations
    Required handlingCaller MUST handle constraint violations: - 2627: Unique constraint violation - 547: Foreign key constraint violation - 515: NOT NULL constraint violation Extract details from error.message. DO NOT retry without fixing data.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[3]
  • execSql · connection-error
    error
    WhenConnection lost during query execution
    ThrowsError event with connection-related error codes
    Required handlingCaller MUST handle connection errors. Connection may be lost due to timeout or server restart. Implement retry with exponential backoff.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • execSql · deadlock
    error
    WhenTransaction deadlock detected
    ThrowsError event with error.number = 1205
    Required handlingCaller MUST handle deadlock errors. Deadlocks are transient - implement retry logic. SQL Server automatically rolls back deadlocked transaction. Consider transaction isolation level and lock hints to reduce deadlocks.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[4]
  • execSql · timeout
    error
    WhenQuery execution timeout exceeded
    ThrowsError event with ETIMEOUT code
    Required handlingCaller MUST handle timeout errors. Query took longer than request timeout setting. Consider optimizing query or increasing timeout.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[2]
  • callProcedure · procedure-error
    error
    WhenStored procedure raises error or does not exist
    ThrowsError event on Request with SQL Server error number
    Required handlingCaller MUST handle 'error' event on Request. Error numbers: - 2812: Procedure not found - Application errors: RAISERROR in procedure Check error.number and error.message for details.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[2]
  • callProcedure · connection-error
    error
    WhenConnection lost during procedure call
    ThrowsError event with connection-related error codes
    Required handlingCaller MUST handle connection errors. Implement retry with exponential backoff for transient issues.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • beginTransaction · transaction-start-error
    error
    WhenCannot start transaction due to connection issues
    ThrowsError event on Connection with transaction error details
    Required handlingCaller MUST handle 'error' event on Connection. Connection must be in LoggedIn state to begin transaction. Ensure no other transaction is active on connection.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • beginTransaction · nested-transaction-error
    error
    WhenAttempting to begin transaction when one is already active
    ThrowsError event indicating transaction already in progress
    Required handlingCaller MUST track transaction state. SQL Server supports nested transactions via SAVE TRANSACTION. Consider using savepoints for nested logic.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[5]
  • commitTransaction · commit-error
    error
    WhenCannot commit transaction (constraint violation, business rule failure)
    ThrowsError event on Connection with commit failure details
    Required handlingCaller MUST handle 'error' event on Connection. Commit can fail if deferred constraints are violated. Transaction will be rolled back automatically on commit failure.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • commitTransaction · no-active-transaction
    error
    WhenAttempting to commit when no transaction is active
    ThrowsError event indicating no transaction to commit
    Required handlingCaller MUST track transaction state. Ensure beginTransaction was called and no prior rollback occurred.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • rollbackTransaction · rollback-error
    error
    WhenCannot rollback transaction (connection lost)
    ThrowsError event on Connection with rollback failure details
    Required handlingCaller MUST handle 'error' event on Connection. Rollback rarely fails; if it does, connection may be unusable. Consider closing and reopening connection after rollback failure.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • rollbackTransaction · no-active-transaction
    error
    WhenAttempting to rollback when no transaction is active
    ThrowsError event indicating no transaction to rollback
    Required handlingCaller MUST track transaction state. Ensure beginTransaction was called.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • prepare · prepare-error
    error
    WhenSQL syntax error or invalid statement
    ThrowsError event on Request with SQL Server error details
    Required handlingCaller MUST handle 'error' event on Request. Prepare validates SQL syntax before execution. Error numbers same as execSql (102, 156, 207, 208).
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[2]
  • unprepare · unprepare-error
    error
    WhenCannot unprepare statement (connection lost, invalid handle)
    ThrowsError event on Request with error details
    Required handlingCaller MUST handle 'error' event on Request. Unprepare should always be called to free server resources.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[2]
  • execute · execute-parameter-validation-error
    error
    WhenParameter value type does not match the declared parameter type (e.g., passing a string where an Int parameter is expected). Validation runs synchronously in execute() via DataType.validate() before any network call.
    ThrowsRequestError delivered to Request callback (code: undefined)
    Required handlingCaller MUST handle 'error' event on the Request object. Parameter type mismatches are caught before the request is sent to SQL Server. Validate parameter types before calling execute(). The same error handler used for prepare()/unprepare() MUST also cover execute().
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • execute · execute-invalid-state-error
    error
    Whenexecute() is called while the connection is not in LOGGED_IN state — e.g., a prior request is still in-flight, or the connection is closing. SQL Server allows only one request at a time per connection.
    ThrowsRequestError with code 'EINVALIDSTATE' delivered to Request callback
    Required handlingCaller MUST wait for the previous request's callback before calling execute(). Only one request at a time per Connection is allowed. Use connection pooling (e.g., mssql) to run concurrent queries. Always handle the 'error' event.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][6]
  • execBulkLoad · bulk-load-constraint-violation
    error
    WhenBulk insert violates a table constraint — e.g., unique key violation (error 2627), foreign key constraint (error 547), NOT NULL constraint (error 515) — when checkConstraints is enabled in BulkLoad options. Without checkConstraints, SQL Server may bypass constraint checks, causing silent data corruption.
    ThrowsError delivered to BulkLoad callback (err.number = 2627 | 547 | 515)
    Required handlingCaller MUST handle error in the BulkLoad callback: newBulkLoad(table, options, (err, rowCount) => { if (err) { /* handle constraint violation */ } }). Consider enabling checkConstraints: true option to catch violations during insert. Log rowCount on success to confirm all rows were inserted.
    costhighin prodimmediate exceptionusers seedegraded performancevisibilitysilent
    Sources[7][3]
  • execBulkLoad · bulk-load-column-definition-mismatch
    error
    WhenColumn definitions added via bulkLoad.addColumn() do not match the actual table schema (wrong data type, wrong nullable flag, or column doesn't exist). This causes the bulk insert to fail. Attempting to call addColumn() after rows have already been written throws synchronously: "Columns cannot be added to bulk insert after the first row has been written."
    ThrowsError thrown synchronously from addColumn() OR Error delivered to BulkLoad callback
    Required handlingCall addColumn() for ALL columns before writing any rows. Verify column definitions against the live table schema before performing bulk load operations. Always handle the BulkLoad callback for schema errors that surface at insert time.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[7]
  • execBulkLoad · bulk-load-timeout
    error
    WhenBulk load exceeds the timeout configured via bulkLoad.setTimeout() or the connection's requestTimeout. Large datasets or slow networks can exceed the timeout, resulting in the bulk load being considered failed.
    ThrowsRequestError with code 'ETIMEOUT' delivered to BulkLoad callback
    Required handlingSet an appropriate timeout with bulkLoad.setTimeout(ms) for large bulk operations. Default is the Connection's requestTimeout (default: 15000ms). For large datasets, use setTimeout(0) for no timeout or increase it explicitly. Handle ETIMEOUT in the callback and implement retry logic for transient failures.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[7][1]
  • saveTransaction · save-transaction-state-error
    error
    WhensaveTransaction() is called when no active transaction exists, or the connection is not in LOGGED_IN state (e.g., a prior request is still pending, connection is closing). SQL Server requires an active transaction for savepoints.
    ThrowsRequestError with code 'EINVALIDSTATE' delivered to saveTransaction callback
    Required handlingCaller MUST check that beginTransaction() has been called before saveTransaction(). Wait for each request's callback to complete before issuing the next request. Always handle the err argument in the saveTransaction callback.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • saveTransaction · save-transaction-connection-error
    error
    WhenConnection is lost while setting the savepoint. Network failure or server restart during the TRANSACTION_MANAGER request causes an error in the callback.
    ThrowsConnectionError delivered to saveTransaction callback
    Required handlingCaller MUST handle error in the saveTransaction callback. On connection error, the parent transaction state is undefined — roll back and reconnect.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • transaction · transaction-begin-error
    error
    WhenTransaction cannot be started — connection is not in LOGGED_IN state (EINVALIDSTATE), or the connection was lost before beginTransaction completed. The error is delivered to the cb callback: cb(err) with no done argument.
    ThrowsRequestError or ConnectionError delivered to cb(err)
    Required handlingCaller MUST check the err argument in the transaction callback before using done(). If err is set, do NOT call done() — the transaction was never started. Example: connection.transaction((err, done) => { if (err) return handleError(err); ... })
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1]
  • transaction · transaction-commit-error
    error
    WhenTransaction commit fails due to deferred constraint violation, connection loss, or server error during COMMIT. The error is delivered through the done() callback: done(err). If the commit fails and the connection is still LOGGED_IN, tedious automatically attempts to rollback before passing the error to done().
    ThrowsRequestError or ConnectionError delivered through done(err)
    Required handlingCaller MUST handle the err argument in the done() callback. On commit error, do NOT retry the transaction without re-starting it from beginTransaction. The automatic rollback in tedious's transaction() helper means the transaction is already rolled back when done(err) is called. Example: done(err) => { if (err) { /* transaction was rolled back */ } }
    costhighin prodimmediate exceptionusers seedegraded performancevisibilitysilent
    Sources[1]
  • execSqlBatch · exec-sql-batch-invalid-state
    error
    WhenexecSqlBatch() is called while the connection is not in LOGGED_IN state — another request is in-flight, the connection is closing, or was never established. Error message: "Requests can only be made in the LoggedIn state, not the X state."
    ThrowsRequestError with code 'EINVALIDSTATE' delivered to Request callback
    Required handlingCaller MUST wait for the previous request's callback before calling execSqlBatch(). Only one request per connection is allowed at a time. Handle the 'error' event on the Request object.
    costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
    Sources[1][6]

Sources

Every postcondition cites at least one of these. Grouped by source type; numbered to match the footnotes above.

Official documentation

Research notes

Curator notes from SOURCES.md captured when the profile was written so you can verify the reasoning, not just the rules.

tedious - Error Handling Sources

Package: tedious Version: >=18.0.0 Last Updated: 2026-02-26 Research Status: Production-ready, comprehensive analysis complete


Table of Contents

  1. Security
  2. Common Production Bugs
  3. Official Documentation
  4. Error Types & Codes
  5. Architecture Considerations
  6. Production Patterns
  7. Research Completeness

Security

CVE Analysis

Status: ✅ CLEAN - No known CVEs as of 2026-02-26

Databases Searched:

Snyk Health Score:

  • Latest version: 19.2.1 (Feb 2026)
  • Latest non-vulnerable version: 19.2.1
  • Direct vulnerabilities: 0
  • Note: Excludes dependency vulnerabilities
  • Weekly downloads: 2,333,494
  • Dependents: 837

References:


Minimum Safe Version: >=18.0.0

Rationale:

  1. No specific CVEs found, but older versions lack modern security practices
  2. Version 18+ aligns with Node.js 18 LTS support (requires 18.17+)
  3. Active maintenance on 18.x and 19.x releases (2024-2026)
  4. Major version jumps (14 → 15 → 18 → 19) suggest significant improvements
  5. Versions below 18 may have unpatched issues not publicly disclosed

Version History:

  • v19.2.1 (Feb 2026): Latest, FeatureExt generation rework
  • v19.2.0 (Dec 2024): Stable release
  • v18.x (2023-2024): Modern Node.js LTS support
  • v14.7.0 (Jun 2022): Added NTLM support on Node.js 17+

References:


Security Best Practices

Encryption

Authentication

Error Handling

  • Information Disclosure: Avoid exposing error details to clients
  • Logging: Log errors securely, sanitize sensitive data
  • Event Listeners: ALWAYS attach error listeners to prevent crashes
  • Reference: https://tediousjs.github.io/tedious/

Common Production Bugs

1. Missing Error Event Listeners ⚠️ CRITICAL

Frequency: Extremely High (appears as #1 in official FAQ)

Error Message:

Uncaught Error: [error details]
Application crashes

Root Cause: No error listener attached to Connection or Request objects.

Official Documentation Quote:

"You must always attach an error listener to created connections, as whenever something goes wrong with the connection it will emit an error and if there is no listener it will crash your application with an uncaught error."

Impact: Application crash on ANY database error (100% reproducible)

Solution:

// REQUIRED pattern
const connection = new Connection(config);
connection.on('error', (err) => {
  console.error('Connection error:', err);
  // Handle error appropriately
});

const request = new Request(sql, callback);
request.on('error', (err) => {
  console.error('Request error:', err);
  // Handle error appropriately
});

Severity: ERROR (application crash)

Reference: https://tediousjs.github.io/tedious/


2. Concurrent Query Execution ⚠️ CRITICAL

Frequency: Very High (appears in FAQ)

Error Message:

Requests can only be made in the LoggedIn state, not the SentClientRequest state

Root Cause: Multiple queries executed simultaneously on single connection without waiting for previous query completion.

Impact: Application crash or incorrect results

Technical Details: Tedious maintains connection state machine. Only one request can be active at a time. Attempting concurrent execution causes state error.

Solution:

// WRONG - concurrent queries
connection.execSql(request1);
connection.execSql(request2); // ERROR!

// RIGHT - sequential execution
connection.execSql(request1);
request1.on('requestCompleted', () => {
  connection.execSql(request2);
});

// BEST - use connection pooling
// With pooling, different queries use different connections

Severity: ERROR (application crash)

Reference: https://tediousjs.github.io/tedious/frequently-encountered-problems.html


3. Connection Configuration Errors

Frequency: High

Common Causes:

  1. SQL Server Browser not running
    • Required for named instances
    • Default port 1434 must be open
  2. TCP/IP not enabled
    • Must enable via SQL Server Configuration Manager
  3. User account disabled
    • Verify in SQL Server Management Studio
  4. Port number not specified
    • Must be in options.port, NOT authentication.options.port
  5. Azure AD clientId missing
    • Now mandatory for azure-active-directory-password auth
    • Microsoft's default client ID removed (not MS-owned driver)

Impact: Cannot establish connection to SQL Server

Solution: Verify all SQL Server prerequisites before debugging connection code.

Severity: ERROR (connection failure)

Reference: https://tediousjs.github.io/tedious/frequently-encountered-problems.html


4. Event-Based API Misuse

Frequency: High

Root Cause: Developers expect promise-based API; tedious uses event-based API by design.

Impact: Incorrect async flow, missing results, uncaught errors

Technical Details: Tedious is fundamentally event-driven (TDS protocol is streaming). Cannot use async/await directly without manual promisification.

Solution:

// Manual promisification
function execSqlPromise(connection, sql) {
  return new Promise((resolve, reject) => {
    const rows = [];
    const request = new Request(sql, (err) => {
      if (err) reject(err);
      else resolve(rows);
    });
    request.on('row', (columns) => rows.push(columns));
    connection.execSql(request);
  });
}

// RECOMMENDED: Use mssql package wrapper
const mssql = require('mssql');
const result = await mssql.query('SELECT * FROM users');

Severity: WARNING (API design difference)

Reference: https://tediousjs.github.io/tedious/


5. Missing Connection Pooling

Frequency: High

Root Cause: Tedious does NOT include connection pooling. Developers create too many connections.

Impact: Resource exhaustion, poor performance under load

Technical Details: Without pooling:

  • Each request creates new connection (expensive)
  • Limited by SQL Server max connections (default: 32,767)
  • Connection overhead dominates query time

Solution:

// Option 1: tedious-connection-pool
const ConnectionPool = require('tedious-connection-pool');
const pool = new ConnectionPool(poolConfig, connectionConfig);

// Option 2: mssql package (RECOMMENDED)
const mssql = require('mssql');
const pool = new mssql.ConnectionPool(config);
await pool.connect();

Severity: PERFORMANCE (critical for production)

References:


6. Incomplete Aggregate Error Handling

Frequency: Medium

Root Cause: Tedious returns AggregateError objects; developers only check top-level error.

Technical Details: Tedious accumulates errors along process for full backtrace. Example: Azure token retrieval errors overwrite previous errors, so AggregateError preserves all.

Impact: Missing critical error details, incomplete debugging information

Solution:

request.on('error', (err) => {
  if (err.errors && Array.isArray(err.errors)) {
    // Loop through all accumulated errors
    err.errors.forEach((e, index) => {
      console.error(`Error ${index + 1}:`, e);
    });
  } else {
    console.error('Error:', err);
  }
});

Severity: WARNING (incomplete error information)

Reference: https://tediousjs.github.io/tedious/frequently-encountered-problems.html


7. JavaScript Number Overflow

Frequency: Medium (common in financial/ID fields)

Root Cause: Values outside -9007199254740991 to 9007199254740991 exceed JavaScript Number precision.

Affected Types:

  • SQL Server BIGINT
  • Large financial values (beyond safe integer range)
  • Large ID values (e.g., Twitter snowflake IDs)

Impact: Data corruption, precision loss

Example:

// SQL Server: SELECT CAST(9007199254740993 AS BIGINT)
// JavaScript receives: 9007199254740992 (rounded!)

Solution:

// Option 1: Use VarChar type
// In SQL: CAST(bigint_column AS VARCHAR(50))

// Option 2: Use BigInt (ES2020+)
const config = {
  options: {
    useUTC: false,
    enableArithAbort: true,
    useBigInt: true  // Tedious 15+ supports BigInt
  }
};

Severity: ERROR (data corruption risk)

Reference: https://tediousjs.github.io/tedious/frequently-encountered-problems.html


8. Unhandled Transaction Deadlocks

Frequency: Medium

Error Code: 1205

Root Cause: Developers don't expect or handle deadlocks; assume transactions always succeed.

Impact: Transaction rollback, lost work, application error

Technical Details: SQL Server automatically detects deadlocks and rolls back one transaction (deadlock victim). Error 1205 is transient and retryable.

Solution:

async function executeWithRetry(fn, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fn();
    } catch (err) {
      if (err.number === 1205 && i < maxRetries - 1) {
        // Deadlock detected, retry with exponential backoff
        await sleep(Math.pow(2, i) * 100);
        continue;
      }
      throw err;
    }
  }
}

Severity: ERROR (transaction failure)

References:


9. Unhandled Constraint Violations

Frequency: High

Error Codes:

  • 515: NOT NULL constraint violation
  • 547: Foreign key constraint violation
  • 2627: Unique constraint violation (duplicate key)

Root Cause: Developers don't check error.number for constraint violation types.

Impact: Application crash or poor error messages to users

Solution:

request.on('error', (err) => {
  switch (err.number) {
    case 2627:
      // Duplicate key
      res.status(409).json({ error: 'Record already exists' });
      break;
    case 547:
      // Foreign key violation
      res.status(400).json({ error: 'Referenced record does not exist' });
      break;
    case 515:
      // NOT NULL violation
      res.status(400).json({ error: 'Required field missing' });
      break;
    default:
      // Generic error
      res.status(500).json({ error: 'Database error' });
  }
});

Severity: ERROR (poor UX, potential crash)

Reference: https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors


10. TLS Version Compatibility Issues

Frequency: Medium

Root Cause: Node.js 12+ requires TLS 1.2 minimum; older SQL Servers may only support TLS 1.0.

Impact: Connection failure

Error Message:

Error: Connection failed: SSL routines:ssl3_get_record:wrong version number

Solution:

# Option 1: Upgrade SQL Server to TLS 1.2 (RECOMMENDED)
# Option 2: Use --tls-min-v1.0 flag (NOT RECOMMENDED - security risk)
node --tls-min-v1.0 app.js

Security Note: TLS 1.0 is deprecated and has known vulnerabilities. Upgrade server infrastructure instead of downgrading TLS version.

Severity: WARNING (configuration issue)

Reference: https://tediousjs.github.io/tedious/frequently-encountered-problems.html


11. NTLM Authentication Failure on Node.js 17+

Frequency: Low (specific to NTLM users)

Root Cause: OpenSSL 3.0 (Node.js 17+) deprecated md4 algorithm used by NTLM.

Error Message:

Error: error:0308010C:digital envelope routines::unsupported

Solution:

# Option 1: Enable legacy provider (temporary workaround)
node --openssl-legacy-provider app.js

# Option 2: Use different authentication (RECOMMENDED)
# - SQL Server authentication
# - Azure Active Directory authentication

Security Concern: Legacy provider enables deprecated cryptographic algorithms. Not recommended for production.

Severity: WARNING (specific authentication method)

Reference: https://tediousjs.github.io/tedious/frequently-encountered-problems.html


Official Documentation

Primary Resources

  1. Tedious Homepage https://tediousjs.github.io/tedious/ Overview, getting started, basic examples

  2. API Reference - Connection https://tediousjs.github.io/tedious/api-connection.html Connection configuration, events, methods

  3. API Reference - Request https://tediousjs.github.io/tedious/api-request.html Request creation, events, parameter handling

  4. Frequently Encountered Problems https://tediousjs.github.io/tedious/frequently-encountered-problems.html Production bug catalog (official FAQ)

  5. Changelog https://tediousjs.github.io/tedious/changelog.html Version history, breaking changes

  6. GitHub Repository https://github.com/tediousjs/tedious Source code, issues, releases

Microsoft Documentation

  1. Node.js Driver for SQL Server https://learn.microsoft.com/en-us/sql/connect/node-js/node-js-driver-for-sql-server Official Microsoft Node.js driver documentation

  2. SQL Server Error Reference https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors Complete SQL Server error code catalog

  3. Transaction Locking Guide https://docs.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide Deadlock handling, isolation levels, lock hints

  4. BEGIN TRANSACTION Reference https://docs.microsoft.com/en-us/sql/t-sql/language-elements/begin-transaction-transact-sql Transaction syntax, nested transactions, savepoints


Error Types & Codes

Connection Errors

Error CodeDescriptionSeverityRetryable
ESOCKETNetwork/socket errorERRORYes (with backoff)
ELOGINAuthentication failedERRORNo (fix credentials)
ETIMEOUTConnection timeoutERRORYes (with backoff)

Source: https://tediousjs.github.io/tedious/api-connection.html


SQL Syntax Errors

Error CodeDescriptionSeverityRetryable
102Incorrect syntaxERRORNo (fix SQL)
156Incorrect syntax near keywordERRORNo (fix SQL)
207Invalid column nameERRORNo (fix schema)
208Invalid object name (table not found)ERRORNo (fix schema)

Source: https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors


Constraint Violations

Error CodeDescriptionSeverityRetryable
515Cannot insert NULL (NOT NULL violation)ERRORNo (fix data)
547Foreign key constraint violationERRORNo (fix data)
2627Unique constraint violation (duplicate key)ERRORNo (fix data)

Handling Pattern:

  • Check error.number to identify constraint type
  • Return user-friendly error messages (don't retry without fixing data)
  • Extract constraint name from error.message for detailed feedback

Source: https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors


System Errors

Error CodeDescriptionSeverityRetryable
1205Transaction deadlock detectedERRORYes (transient)
2812Could not find stored procedureERRORNo (fix code)

Deadlock Handling (1205):

  • SQL Server automatically rolls back deadlocked transaction
  • Implement retry with exponential backoff
  • Consider transaction isolation level and lock hints to reduce deadlocks

Source: https://docs.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide


Architecture Considerations

Event-Based API Design

Key Characteristic: Tedious uses event-based API (not promise-based) due to TDS protocol's streaming nature.

Implications:

  1. Cannot use async/await directly without promisification
  2. Error handling via event listeners, not try-catch
  3. Cannot await requests without wrapper

Production Recommendation: Use mssql package wrapper for promise-based API with connection pooling.

Reference: https://tediousjs.github.io/tedious/


Connection State Machine

States:

  • Connecting - Initial connection establishment
  • SentPrelogin - Pre-login handshake sent
  • SentClientRequest - Request in progress
  • LoggedIn - Ready for queries
  • Closed - Connection closed

Critical Limitation: Only ONE request can be active at a time (SentClientRequest state). Concurrent requests cause state error.

Reference: https://tediousjs.github.io/tedious/api-connection.html


No Built-In Connection Pooling

Implication: Without pooling, each request creates new connection (expensive).

Production Options:

  1. tedious-connection-pool package
  2. mssql package (RECOMMENDED - includes pooling)
  3. Custom pooling implementation

Reference: https://github.com/tediousjs/tedious-connection-pool


TLS/Encryption Requirements

Modern Requirements:

  • Node.js 12+ requires TLS 1.2 minimum
  • TLS 1.0 deprecated (use --tls-min-v1.0 only as last resort)
  • OpenSSL 3.0 (Node.js 17+) deprecated md4 (affects NTLM)

Configuration Relationships:

  • Server requiring encryption + encrypt: false = connection error
  • encrypt: true + trustServerCertificate: false may require cryptoCredentialsDetails

Reference: https://tediousjs.github.io/tedious/frequently-encountered-problems.html


Production Patterns

✅ Recommended Patterns

  1. Use mssql Package Wrapper

  2. Always Attach Error Listeners

    • Rationale: Prevents application crashes (critical)
    • Adoption: Required
    • Pattern: connection.on('error', handler) and request.on('error', handler)
  3. Implement Connection Pooling

    • Rationale: Performance and resource management
    • Adoption: Recommended for production
    • Options: tedious-connection-pool or mssql
  4. Use Parameterized Queries

    • Rationale: Prevents SQL injection
    • Adoption: Required
    • Pattern: request.addParameter('param', TYPES.VarChar, value)
  5. Handle Deadlocks with Retry Logic

    • Rationale: Deadlocks (error 1205) are transient
    • Adoption: Recommended for transaction-heavy apps
    • Pattern: Exponential backoff retry for error 1205

❌ Anti-Patterns to Avoid

  1. No Error Listeners on Connections/Requests

    • Risk: Application crash on any error
    • Severity: Critical
  2. Concurrent Queries on Single Connection

    • Risk: State errors and crashes
    • Severity: Critical
  3. Not Using Connection Pooling

    • Risk: Resource exhaustion under load
    • Severity: High (performance)
  4. Hardcoded Credentials

    • Risk: Security breach
    • Severity: Critical
  5. Not Checking error.number for Error Types

    • Risk: Poor error handling, incorrect retries
    • Severity: High

Research Completeness

Metrics

  • 11 production bugs identified and documented
  • 10+ SQL Server error codes cataloged
  • 6+ primary documentation sources reviewed
  • CVE analysis complete (0 CVEs found)
  • Version history analyzed (19.2.1 latest, 18.0.0+ recommended)
  • Production patterns documented (5 recommended, 5 anti-patterns)
  • Edge cases identified (9 critical edge cases)

Bug Frequency Analysis

By Severity:

  • Critical: 2 bugs
  • Error: 7 bugs
  • Warning: 1 bug
  • Performance: 1 bug

By Frequency:

  • Extremely High: 1 (missing error listeners)
  • Very High: 1 (concurrent queries)
  • High: 5
  • Medium: 4
  • Low: 1

Package Statistics

  • Weekly Downloads: 2,333,494
  • Dependents: 837
  • GitHub Stars: High activity
  • Versions: 234 releases
  • Latest Version: 19.2.1 (Feb 2026)
  • Node.js Requirement: >=18.17.0

Research Metadata

Research Date: 2026-02-26 Research Duration: Comprehensive multi-phase analysis Analyst: AI Research Agent Confidence Level: High Completeness: Comprehensive (11 bugs, 10+ error codes, 6+ sources)

Phases Completed:

  1. ✅ Planning
  2. ✅ Documentation research
  3. ✅ CVE/security analysis
  4. ✅ Real-world usage analysis
  5. ✅ Contract creation
  6. ✅ Sources documentation

Production Status: READY Contract Status: production Minimum Safe Version: >=18.0.0


Last Updated: 2026-02-26

Need a different package?
Request a profile