"Fixes for TZ_LT14 not applied" -> Until yesterday it worked fine

[cris4414]

Search before asking

• I searched the issues and found no similar issues.

What Happened

I created a custom rule in SQLFLUFF that added a line to set the timezone:
SET TIMEZONE = 'Est/Bucharest';
It detects it when sqlfluff lint, but when I try to fix it with sqlfluff fix it displays:

WARNING Fixes for TZ_LT14 not applied, as it would result in an unparsable file. Please report this as a bug with a minimal query which demonstrates this warning.
WARNING One fix for TZ_LT14 not applied, it would re-cause the same error.

The paradox is that until yesterday the fix was applied without any problems and I did no modifications to the code for this custom rule.

Expected Behaviour

Apply the fix as until yesterday, meaning setting the new line at the beginning of the file:
SET TIMEZONE = 'Est/Bucharest';

Observed Behaviour

The mentioned error

How to reproduce

The code for the _eval() function for the custom rule I implemented:

def _eval(self, context: RuleContext) -> Optional[LintResult]:

    # If the first segment of the file is not equivalent to setting correct timezone, the timezone is set with
    # LintFix

    for seg in context.segment.segments:
        if not seg.raw == (RawSegment("SET TIMEZONE = 'Est/Bucharest'")).raw:
            return LintResult(
                anchor=seg,
                fixes=[LintFix.create_before(seg, [RawSegment("SET TIMEZONE = 'Est/Bucharest'"), SymbolSegment(";"),
                                                   NewlineSegment(), NewlineSegment()])],
            )
        # Only the first segment needs to be linted and fixed
        break
    return None

Example of incorrect sql file:

SELECT * FROM foo;

Example of correct sql file:

SET TIMEZONE = 'Est/Bucharest';

SELECT * FROM foo;

Dialect

Postgres

Version

version 3.0.3

Configuration

[sqlfluff]

Supported dialects https://docs.sqlfluff.com/en/stable/dialects.html

Or run 'sqlfluff dialects'

dialect = postgres

One of [raw|jinja|python|placeholder]

templater = jinja

Comma separated list of rules to exclude, or None

See https://docs.sqlfluff.com/en/stable/configuration.html#enabling-and-disabling-rules

AM04 (ambiguous.column_count) and ST06 (structure.column_order) are

two of the more controversial rules included to illustrate usage.

exclude_rules = ambiguous.column_count, structure.column_order, LT05

From site-packages/sqlfluff/core/default_config.cfg taken:

Ignore errors by category (one or more of the following, separated by commas: lexing,linting,parsing,templating)

ignore = templating, parsing

The standard max_line_length is 80 in line with the convention of

other tools and several style guides. Many projects however prefer

something a little longer.

Set to zero or negative to disable checks.

max_line_length = 120

CPU processes to use while linting.

The default is "single threaded" to allow easy debugging, but this

is often undesirable at scale.

If positive, just implies number of processes.

If negative or zero, implies number_of_cpus - specified_number.

e.g. -1 means use all processors but one. 0 means all cpus.

processes = -1

If using the dbt templater, we recommend setting the project dir.

[sqlfluff:templater:dbt]
project_dir = ./dags

[sqlfluff:indentation]

While implicit indents are not enabled by default. Many of the

SQLFluff maintainers do use them in their projects.

allow_implicit_indents = true

The default configuration for aliasing rules is "consistent"

which will auto-detect the setting from the rest of the file. This

is less desirable in a new project and you may find this (slightly

more strict) setting more useful.

[sqlfluff:rules:aliasing.table]
aliasing = explicit
[sqlfluff:rules:aliasing.column]
aliasing = explicit
[sqlfluff:rules:aliasing.length]
min_alias_length = 3

The default configuration for capitalisation rules is "consistent"

which will auto-detect the setting from the rest of the file. This

is less desirable in a new project and you may find this (slightly

more strict) setting more useful.

Typically we find users rely on syntax highlighting rather than

capitalisation to distinguish between keywords and identifiers.

Clearly, if your organisation has already settled on uppercase

formatting for any of these syntax elements then set them to "upper".

See https://stackoverflow.com/questions/608196/why-should-i-capitalize-my-sql-keywords-is-there-a-good-reason

[sqlfluff:rules:capitalisation.keywords]
capitalisation_policy = upper
[sqlfluff:rules:capitalisation.identifiers]
capitalisation_policy = lower
[sqlfluff:rules:capitalisation.functions]
extended_capitalisation_policy = upper
[sqlfluff:rules:capitalisation.literals]
capitalisation_policy = upper
[sqlfluff:rules:capitalisation.types]
extended_capitalisation_policy = upper

Are you willing to work on and submit a PR to address the issue?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct