text:
Implement NumPy 2.0 migration rule

Summary

Hi! Currently NumPy Python API is undergoing a cleanup process that will be delivered in NumPy 2.0 (release is planned for the end of the year).
Most changes are rather simple (renaming, removing or moving a member of the main namespace to a new place), and they could be flagged/fixed by an additional ruff rule for numpy (e.g. changing occurrences of np.float_ to np.float64).
Would you accept such rule?
I named it NPY201 in the existing group, so people will receive a heads-up for changes arriving in 2.0 before actually migrating to it.
This is still a draft PR. I'm not an expert in rust so if any part of code can be done better please share!
NumPy 2.0 migration guide: https://numpy.org/devdocs/numpy_2_0_migration_guide.html
NEP 52: https://numpy.org/neps/nep-0052-python-api-cleanup.html
NumPy cleanup tracking issue: https://github.com/numpy/numpy/issues/23999
Test Plan

TODO

Happy to include something like this. I need to think a bit more on whether this should be its own rule, or whether we should just extend deprecated_function (and add a deprecated_constant for the remaining rules).
As of what NumPy version are these fixes safe? As in, are there older, supported versions of NumPy for which applying these rules would cause issues? (Ultimately asking: will Ruff need to know the NumPy version?)

Thank you for the feedback! All these breaking changes will be shipped in 2.0.0 version that is planned for this December. The latest release of numpy is 1.26.0.
Only nightly 2.0.0.dev0 and future 2.0.0 versions are safe to apply these changes.
For past releases these are incompatible ones, therefore we thought to establish it as a separate rule. Downstream users that are still on 1.x would upgrade ruff and get a heads-up errors, which they can suppress by disabling the rule.
Once they decide to upgrade to 2.0 they can run ruff with --fix and get most of changes done (and these renames can be mundane to do manually - I did them for numpy, scipy, etc. and it was magnitude of hundreds of lines of changed code).
If ruff would know numpy version then it could be used to determine whether to apply this rule.

Thanks @mtsokol. Sorry if I'm misunderstanding, but some of these fixes would be safe to apply in older versions, right? For example, the rules that suggest using np.inf would be safe to apply, since np.inf exists in older versions, etc.

@charliermarsh Ah yes! Actually most of changes from the NumPy 2.0 migration guide can be applied to the previous versions. (My last response was confusing - only a few are backward incompatible, e.g. renaming np.int_ to np.long (https://github.com/numpy/numpy/pull/24794) or moving np.byte_bounds to np.lib.array_utils. Right now I'm working on these renames and I forgot to mention that it's just a fraction of all changes).
np.Infinity -> np.inf, np.float_ -> np.float64 etc. are all backward compatible and are safe to apply to previous versions.

The PR's blueprint is ready from my side - it consist of three types of AST fixes:

AutoImport: the deprecated member of the numpy namespace can be replaced with another, e.g. np.float_ with np.float64 or np.INF with np.inf.
AutoPurePython: the deprecated member can be replaced with python expression, e.g. np.NZERO with -0.0 or np.issubclass_ with issubclass.
Manual: can't be automatically fixed - a guideline is provided on how to fix it.

I the shape is correct I will provision the rest of entries and exhaustive unit test. Please share your feedback!
P.S. I get some errors in the CI that I can't reproduce locally:
  |
1 | use ruff_diagnostics::{AutofixKind, Diagnostic, Edit, Fix, Violation};
  |                        ^^^^^^^^^^^ no `AutofixKind` in the root

I followed implementation of other numpy rules. What am I missing?

@mtsokol - We recently renamed AutofixKind to AutofixAvailability, so you might be running into something like: GitHub is rebasing your PR on main prior to testing, and so the name doesn't exist anymore.

@mtsokol - We recently renamed AutofixKind to AutofixAvailability, so you might be running into something like: GitHub is rebasing your PR on main prior to testing, and so the name doesn't exist anymore.

Thank you! Now CI tests are passing.

It looks like you are not changing NaN to nan. Per https://numpy.org/devdocs/numpy_2_0_migration_guide.html

It looks like you are not changing NaN to nan. Per https://numpy.org/devdocs/numpy_2_0_migration_guide.html

We're still finishing adding new changes but here it's just a matter of adding new entries to match in the rule (I will add the rest soon!). I was curious if the overall design of PR and three types of fixes proposed looks correct.

Hi @charliermarsh @Hoxbro,
We finished Python API refactoring for NumPy 2.0. I updated this PR - now the new rule contains all changes introduced to the main namespace (i.e. members' removals).
Out of all 52 cases in the rule only one is backward incompatible. 51 remaining ones are relevant for both NumPy 1.x and 2.0 releases and contribute to cleaner codebase regardless of NumPy version used.
I added a unit test that checks all rule's fix cases.

Thanks @mtsokol -- will queue this up for review and try to get to it shortly.

(Sorry for the delay on this -- we shipped our formatter earlier this week and I've been busy with follow-ups from the release. This is still on my list.)

This looks great, thanks @mtsokol! I like the way you structured the rule -- it reads well.
I took some liberties in editing the rule documentation and tweaking a few of the migration messages, with the goal of making them a little more consistent with the copy and voice we use in other rules. If you have any feedback or issues with the changes, just let me know, happy to address in a follow-up PR.

Shouldn't the new numpy imports happen at the same level as the existing numpy import?

@charliermarsh Hi, all tweaks look good to me - thank you for a review!

Hello! As a user who does not know much about ruff internals, how do I try this out downstream? Do I only have to modify https://github.com/astropy/astropy/blob/main/.ruff.toml ? If so, how? Is this documented somewhere?

@Hoxbro - Can you give an example of where this is happening?

@pllim -- You shouldn't need to modify your configuration, but you would need to build from source, which just means that you need to have Rust installed. If you have Rust installed, then you should be able to run something like:
cargo run -p ruff_linter -- check ../path/to/astropy --select NPY --preview

but you would need to build from source

Oh, so this isn't one of those code I can just add to the TOML? Or maybe I can in the future when this feature is released?
Not sure if I want to install rust and build this from source on a CI for a Python package.

@pllim -- It'll be available in the next release (it was just merged last night), so later today or early next week.

It'll be available in the next release

And after that, I can just edit my .ruff.toml to use this?

@pllim yep!

What codes are available? Is there a page where I can look this up? Thanks!!

Everything on the rules page is available in the latest release. (We only update the documentation when we release.)

authors: Hoxbro charliermarsh mtsokol pllim zanieb


text:
I need the option without venv

Hi.
I think rye is more useful if there was an option to not use venv like poetry config virtualenvs.create false.

Can you please share more about your use-case?

A use case could be using rye within a conda environment. I was just wondering the same thing. I installed sagemath in conda and I'd like to add some regular packages as well managed by a pyproject.toml file.

I sometimes manage python versions by python image in Docker.
If I use rye to do this, it creates a venv environment that I don't need.

source: gharchive/issue

authors: RyosukeDTomita njmaeff zanieb

repo: astral-sh/rye

license: MIT

license_type: permissive

license_source: github-api


text:
uv pip install --no-deps fails due to conflicting requirements even though the --no-deps flag is given

Context
I have a special use case for a client whereby I need to provide some libraries which they install via a requirements.txt.
The purpose of this file is only to list the libraries I provide (as local paths), and there is another requirements file for the external dependencies.
We work like this because in my company we use git dependencies for our own libraries but our client does not have access to our private git repos.
The install instructions for them are to do a pip install for the external dependencies (pulled from PyPI), and then a second pip install with the requirements file I provide them. This works fine with pip, but not with uv pip because the top-level library depends on the other libraries via git dependencies (specified in a pyproject.toml), but they are also listed in the requirements.txt. This leads to:
error: Requirements contain conflicting URLs for package `blargh`:

even though I provide the --no-deps flag. With this flag, it works fine with pip. So it seems to me like there is some conflict resolution that's taking place for the git dependencies that should not be happening with --no-deps.
Here is the full command I run:
uv pip install --no-deps -r requirements.txt

Platform and uv version
I am on Linux with uv 0.1.35.

Thanks, I can guess what's going on here.

authors: bluthej charliermarsh

repo: astral-sh/uv


text:
uv sync --upgrade always gives warning about an old extra for typer

Previously, I was using an older version of typer where you needed to add the typer[all] extra to get full functionality. I deleted that extra since it is no longer needed, but for some reason, whenever I run uv sync --upgrade, I get warning messages about it. Seems like maybe this old dep config is sticking around in a cache somewhere?
❯ uv sync --upgrade
Resolved 79 packages in 956ms
warning: The package `typer==0.12.5` does not have an extra named `all`
Audited 75 packages in 0.28ms

[project]
dependencies = [
  .
  .
  .
  "sqlmodel>=0.0.22",
  "stamina>=24.3.0",
  "tenacity>=9.0.0",
  "typer>=0.12.5",
  "ujson>=5.10.0",
  "uvicorn[standard]>=0.32.0",
]

Hello, do you have a way to reproduce? I wasn't able to reproduce.
I don't see an extra in typer  called all in 0.12.5.
It seems 0.11.x did have it.
When I installed 0.11.x with all and upgraded it to 0.12.5 I didn't get a warning unless all was still referenced in pyproject.toml.

I need to try a minimal example as well, but what you are describing is more or less what I believe I did. I do have other deps that also rely on typer and it may be possible that they had typer[all] in their pyproject.toml, but I also did not see anything that looked like an extra related to typer anywhere in my project.

It seems likely the request comes from a transitive dependency?
We just display this warning whenever we look at a package request https://github.com/astral-sh/uv/blob/5ab860be20e75451c3c9c779c5f552b3fd0cb2ad/crates/uv-resolver/src/resolution/graph.rs#L347-L354
I don't think it'd be easy for us to display where the request came from in this context.

I was getting this exact warning today when i was upgrading a FastAPI app from Poetry to uv. Turns out I had forgotten to delete the OLD .venv from Poetry which still had an older version of something that wanted typer[all]. Deleted the .venv and issue was gone.

@zanieb @seapagan Okay, that makes sense. Thanks for the confirmation!

authors: samypr100 seapagan taranlu-houzz zanieb


text:
Use mimalloc on MacOS and Linux

Summary
mimalloc tends to provide performance benefits, especially in multi-threaded scenarios, and even more when using work-stealing schedulers where data is migrated across threads between allocation and de-allocation. Currently, we only use mimalloc on Windows, but we can also use it on MacOS and Linux (mimalloc supports more platforms than this, but those seem to be the only officially supported ones https://github.com/microsoft/mimalloc/issues/482#issuecomment-953190795).
Test Plan
On Linux, I'm seeing between 15-30% performance improvements on the install-warm and resolve-warm benchmarks. On M1 I'm seeing a slight regression, so it might only be beneficial to switch on Linux, but I want to see the results on other machines first.
We should also test the memory usage affects of this change.

I did some benchmarking on my M3. Hard to draw firm conclusions but I think I see something like a 5-10% regression in install-warm for ./scripts/requirements/compiled/jupyter.txt (replicated in three runs with --min-runs 50 --warmup 20), although in one run, this branch was 5% faster. I'd probably err on the side of not changing the allocator on macOS based on that, though.

Resolutions on ubuntu 22.04 on a 16 core / 32 thread i9-13900K:
jupyter:
Benchmark 1: target/profiling/uv-main pip compile scripts/requirements/jupyter.in
  Time (mean ± σ):      14.4 ms ±   0.8 ms    [User: 15.0 ms, System: 15.9 ms]
  Range (min … max):    12.8 ms …  17.4 ms    200 runs

Benchmark 2: target/profiling/uv-branch pip compile scripts/requirements/jupyter.in
  Time (mean ± σ):      15.2 ms ±   0.9 ms    [User: 14.1 ms, System: 20.0 ms]
  Range (min … max):    13.1 ms …  18.6 ms    211 runs

Summary
  target/profiling/uv-main pip compile scripts/requirements/jupyter.in ran
    1.05 ± 0.09 times faster than target/profiling/uv-branch pip compile scripts/requirements/jupyter.in

The jupyter install benchmark is only noise for me unfortunately.
airflow:
Benchmark 1: target/profiling/uv-main pip compile airflow.in
  Time (mean ± σ):     154.9 ms ±   2.7 ms    [User: 148.1 ms, System: 128.2 ms]
  Range (min … max):   149.7 ms … 160.0 ms    19 runs

Benchmark 2: target/profiling/uv-branch pip compile airflow.in
  Time (mean ± σ):     150.6 ms ±   3.5 ms    [User: 146.3 ms, System: 133.6 ms]
  Range (min … max):   146.4 ms … 158.3 ms    20 runs

Summary
  target/profiling/uv-branch pip compile airflow.in ran
    1.03 ± 0.03 times faster than target/profiling/uv-main pip compile airflow.in

boto3:
Benchmark 1: target/profiling/uv-main pip compile scripts/requirements/boto3.in
  Time (mean ± σ):     356.3 ms ±   0.9 ms    [User: 322.2 ms, System: 45.2 ms]
  Range (min … max):   355.2 ms … 357.6 ms    10 runs

Benchmark 2: target/profiling/uv-branch pip compile scripts/requirements/boto3.in
  Time (mean ± σ):     355.1 ms ±   1.7 ms    [User: 323.1 ms, System: 44.0 ms]
  Range (min … max):   352.0 ms … 358.0 ms    10 runs

Summary
  target/profiling/uv-branch pip compile scripts/requirements/boto3.in ran
    1.00 ± 0.01 times faster than target/profiling/uv-main pip compile scripts/requirements/boto3.in

I don't mind the 0.8ms (that's ms, not s) more for jupyter since it doesn't affect more complex resolutions.
I'm all for merging this just for removing the tikv-jemallocator dependency and the simpler cfg's.

macOS (M1 Pro)
❯ python -m scripts.bench \
    --uv-path ./baseline \
    --uv-path ./target/release/uv \
    ../prefect/requirements.txt
Benchmark 1: ./baseline (install-cold)
  Time (mean ± σ):      2.074 s ±  0.545 s    [User: 0.484 s, System: 0.856 s]
  Range (min … max):    1.381 s …  2.849 s    10 runs

Benchmark 2: ./target/release/uv (install-cold)
  Time (mean ± σ):      1.960 s ±  0.454 s    [User: 0.457 s, System: 0.842 s]
  Range (min … max):    1.664 s …  3.203 s    10 runs

Summary
  ./target/release/uv (install-cold) ran
    1.06 ± 0.37 times faster than ./baseline (install-cold)
Benchmark 1: ./baseline (install-warm)
  Time (mean ± σ):      66.5 ms ±  12.3 ms    [User: 11.1 ms, System: 99.8 ms]
  Range (min … max):    53.2 ms …  88.1 ms    10 runs

Benchmark 2: ./target/release/uv (install-warm)
  Time (mean ± σ):      72.0 ms ±  14.1 ms    [User: 10.3 ms, System: 99.9 ms]
  Range (min … max):    53.3 ms …  92.1 ms    10 runs

Summary
  ./baseline (install-warm) ran
    1.08 ± 0.29 times faster than ./target/release/uv (install-warm)

❯ python -m scripts.bench \
    --uv-path ./baseline \
    --uv-path ./target/release/uv \
  ./scripts/requirements/compiled/jupyter.txt
Benchmark 1: ./baseline (install-cold)
  Time (mean ± σ):      3.514 s ±  0.931 s    [User: 0.864 s, System: 1.726 s]
  Range (min … max):    2.228 s …  5.212 s    10 runs

Benchmark 2: ./target/release/uv (install-cold)
  Time (mean ± σ):      3.544 s ±  1.190 s    [User: 0.882 s, System: 1.725 s]
  Range (min … max):    2.321 s …  5.626 s    10 runs

Summary
  ./baseline (install-cold) ran
    1.01 ± 0.43 times faster than ./target/release/uv (install-cold)
Benchmark 1: ./baseline (install-warm)
  Time (mean ± σ):     213.7 ms ±  19.1 ms    [User: 29.0 ms, System: 226.1 ms]
  Range (min … max):   177.2 ms … 238.9 ms    10 runs

Benchmark 2: ./target/release/uv (install-warm)
  Time (mean ± σ):     206.3 ms ±  23.8 ms    [User: 28.4 ms, System: 224.4 ms]
  Range (min … max):   177.7 ms … 257.9 ms    10 runs

Summary
  ./target/release/uv (install-warm) ran
    1.04 ± 0.15 times faster than ./baseline (install-warm)

❯ python -m scripts.bench \
    --uv-path ./baseline \
    --uv-path ./target/release/uv \
  ./scripts/requirements/boto3.in
Benchmark 1: ./baseline (resolve-cold)
  Time (mean ± σ):      2.883 s ±  0.176 s    [User: 0.921 s, System: 0.819 s]
  Range (min … max):    2.645 s …  3.159 s    10 runs

Benchmark 2: ./target/release/uv (resolve-cold)
  Time (mean ± σ):      2.906 s ±  0.571 s    [User: 0.875 s, System: 0.770 s]
  Range (min … max):    2.116 s …  3.903 s    10 runs

Summary
  ./baseline (resolve-cold) ran
    1.01 ± 0.21 times faster than ./target/release/uv (resolve-cold)
Benchmark 1: ./baseline (resolve-warm)
  Time (mean ± σ):     482.8 ms ±  44.0 ms    [User: 429.6 ms, System: 123.7 ms]
  Range (min … max):   437.9 ms … 560.1 ms    10 runs

Benchmark 2: ./target/release/uv (resolve-warm)
  Time (mean ± σ):     516.9 ms ± 104.1 ms    [User: 422.6 ms, System: 127.4 ms]
  Range (min … max):   420.3 ms … 721.9 ms    10 runs

Summary
  ./baseline (resolve-warm) ran
    1.07 ± 0.24 times faster than ./target/release/uv (resolve-warm)

Linux (AMD Ryzen 7 3800X)
❯ python3 -m scripts.bench \
    --uv-path ./baseline \
    --uv-path ./target/release/uv \
  ./scripts/requirements/compiled/jupyter.txt
Benchmark 1: ./baseline (install-cold)
  Time (mean ± σ):      3.976 s ±  0.960 s    [User: 0.951 s, System: 0.669 s]
  Range (min … max):    2.351 s …  5.159 s    10 runs

Benchmark 2: ./target/release/uv (install-cold)
  Time (mean ± σ):      3.926 s ±  0.955 s    [User: 0.925 s, System: 0.695 s]
  Range (min … max):    2.997 s …  6.253 s    10 runs

Summary
  ./target/release/uv (install-cold) ran
    1.01 ± 0.35 times faster than ./baseline (install-cold)
Benchmark 1: ./baseline (install-warm)
  Time (mean ± σ):      82.4 ms ±  19.2 ms    [User: 46.1 ms, System: 101.0 ms]
  Range (min … max):    53.6 ms … 116.9 ms    10 runs

Benchmark 2: ./target/release/uv (install-warm)
  Time (mean ± σ):      81.4 ms ±  13.9 ms    [User: 45.3 ms, System: 107.6 ms]
  Range (min … max):    62.5 ms … 101.3 ms    10 runs

Summary
  ./target/release/uv (install-warm) ran
    1.01 ± 0.29 times faster than ./baseline (install-warm)

❯ python3 -m scripts.bench \
    --uv-path ./baseline \
    --uv-path ./target/release/uv \
  ./scripts/requirements/boto3.in
Benchmark 1: ./baseline (resolve-cold)
  Time (mean ± σ):      2.542 s ±  0.333 s    [User: 0.943 s, System: 0.286 s]
  Range (min … max):    2.094 s …  3.206 s    10 runs

Benchmark 2: ./target/release/uv (resolve-cold)
  Time (mean ± σ):      2.666 s ±  0.276 s    [User: 0.933 s, System: 0.297 s]
  Range (min … max):    2.332 s …  3.226 s    10 runs

Summary
  ./baseline (resolve-cold) ran
    1.05 ± 0.18 times faster than ./target/release/uv (resolve-cold)
Benchmark 1: ./baseline (resolve-warm)
  Time (mean ± σ):     493.1 ms ±   4.9 ms    [User: 471.1 ms, System: 60.3 ms]
  Range (min … max):   483.7 ms … 500.1 ms    10 runs

Benchmark 2: ./target/release/uv (resolve-warm)
  Time (mean ± σ):     484.7 ms ±   4.4 ms    [User: 467.2 ms, System: 56.6 ms]
  Range (min … max):   478.1 ms … 492.2 ms    10 runs

Summary
  ./target/release/uv (resolve-warm) ran
    1.02 ± 0.01 times faster than ./baseline (resolve-warm)

Not really seeing anything definitive, I think I'd need to run more samples if we want more data for a decision.

I think the warm-resolve benchmarks are so fast that there won't be much signal in them. And the cold benchmarks are so bounded by other things that it's hard to get much signal from them either. So I'd suggest we focus on the warm-install benchmarks, I guess?

I'm going to close this for now, I'm also seeing the regression locally with the new resolver benchmarks, so it's not just CodSpeed.

@ibraheemdev just be warned, I think allocations are "free" and not part of the measurements in CodSpeed.
cc @MichaReiser

I’m generally fine to merge this for Linux at least if we see some improvements in the warm install.

Yeah the 20% speed-up on Linux seemed nice.

@zanieb Can you run cargo bench --bench uv locally? I'm seeing a large regression on that benchmark on my Linux machine.

I don't see a large regression on my Linux machine.
❯ cargo bench --bench uv
resolve_warm_jupyter    time:   [12.663 ms 12.739 ms 12.816 ms]
                        change: [+1.2044% +1.9636% +2.6014%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

❯ cargo bench --bench uv
resolve_warm_jupyter    time:   [12.460 ms 12.516 ms 12.571 ms]
                        change: [-2.4970% -1.7496% -1.0174%] (p = 0.00 < 0.05)
                        Performance has improved.

@ibraheemdev just be warned, I think allocations are "free" and not part of the measurements in CodSpeed.

Yes and no. The alloc syscall is free, but not the alloc of a custom memory allocator. CodSpeed will measure the instructions in the custom allocator the same as our user code. In general, all syscalls are free (which I think should be fixed because they're the most expensive calls).
That means, codspeed will not measure if this PR e.g. reduces the calls to the system alloc (or free to that matter) function. But it still measures how many other non-syscall instructions our code runs.

source: gharchive/pull-request

authors: MichaReiser charliermarsh ibraheemdev konstin zanieb


text:
Remove unused datasets

Description
What is the current behavior?
We are not using this dataset for benchmarking, we should remove it. Also, there was a failure for the StackExchange dataset.

End-users use real datasets, which has allowed us to surface several issues with our stack. Much more than any synthetic dataset we have.
I believe we should have end-to-end tests that use these datasets instead of simply getting rid of them.

I agree @tatiana , but currently, we are not using it in our code base anywhere. When do we start doing that we can add them again to the codebase, WDYT? we can maybe create a ticket(s) to add a test case with a real dataset?

I'm happy for them to be removed and re-introduced as long as we have a task logged for us to have e2e tests using realistic datasets, referencing this PR :)

@tatiana Added a ticket for the same - https://github.com/astronomer/astro-sdk/issues/1612

Most of these data we have stored in gcs do you want to keep it or we should clean them also example gs://astro-sdk/benchmark/trimmed/github/github_timeline_100mb.csv @utkarsharma2 ?

We should do that as well. I'll merge this PR for now. I'll create a separate ticket for this.

repo: astronomer/astro-sdk


text:
Render vars when parsing DbtModel

When parsing DbtModel if I have vars in sql file and I fail to get valid upstream_models.
-- sql file
SELECT
    column_1,
	column_2,
FROM {{ ref('stg_users_'~ var('country_code')) }}

-- model
- name: stg_users_{{ var("country_code") }}
  columns:
	...

For instance, if I have sql file and model file as above during __post_init__ of DbtModel method, the referenced model is not added to config.upstream_models since it is not jinja2.nodes.Const type (If I have vars it is Concat type). I use vars in ref because I define single model configuration for multiple country codes.
-- something like this
 Concat(nodes=[Const(value='stg_users_'), Call(node=Name(name='var', ctx='load'), args=[Const(value='country_code')], kwargs=[], dyn_args=None, dyn_kwargs=None)]))

https://github.com/astronomer/astronomer-cosmos/blob/56d38b9a38ccc7fbe17cdcb2debb71e04f518c8b/cosmos/dbt/parser/project.py#L166-L175
So is it possible to receive vars in DbtModel and render ref value and add it to upstream_models? I want something like the following logic added
if isinstance(first_arg, jinja2.nodes.Concat):
    value = ''
    for node in base_node.args[0].nodes:
        if isinstance(node, jinja2.nodes.Const):
            value += node.value
        elif isinstance(node, jinja2.nodes.Call):
            if node.node.name == 'var':
                value += self.task_args[node.args[0].value]

The feature totally makes sense, @dojinkimm, thanks for writing it down!
Would you like to contribute with a PR for this change?

@tatiana Sure, I will try PR for this change

@tatiana I recently opened PR but it is not reviewed yet. Do I need to do something more to be reviewed?

Sorry for the delay, @dojinkimm , I'm looking into it now!

@dojinkimm We released the fix as part of 1.1.1:
https://github.com/astronomer/astronomer-cosmos/releases/tag/astronomer-cosmos-v1.1.1
However, you mentioned that you were on 0.6.8. How likely are you to upgrade to the latest Cosmos? Please let us know if there are any blockers.

authors: dojinkimm tatiana

repo: astronomer/astronomer-cosmos


text:
Fix redshift sql example DAG

Example DAG for the Async redshift SQL operator has unlinked tasks which is causing the integration tests to fail.

This bug is a result of changes done as part of #63

repo: astronomer/astronomer-providers


text:
New rectangular box type having two opposite corner points.

casa region has a box type , box[ [x1, y1], [x2, y2] ] , the two coordinates are two opposite corners.
so, do we want to create a new region class for that? , or convert into current rectangle format to handle that.

Convert to rectangle.  They are equivalent.

Done by @sushobhana in #202 (still not merged)

authors: cdeil keflavich sushobhana

repo: astropy/regions


text:
feat(post): implement post viewer feature

this PR resolves #7

:tada: This PR is included in version 1.0.0-dev.1 :tada:
The release is available on:

GitHub release
v1.0.0-dev.1

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

v1.0.0
GitHub release
v1.0.0

Your semantic-release bot :package::rocket:


text:
Update installation-guide.md

Resolved the issue #3190

Description

The link was broken. Tried to fix it.
Current Link: https://github.com/marketplace/actions/generator-for-asyncapi-documents
Correct Link: https://github.com/marketplace/actions/generator-validator-converter-and-others-all-in-one-for-your-asyncapi-docs

Related issue(s)

Please open these PR in generator repo as we maintained these docs there

repo: asyncapi/website


text:
Uncaught, unspecified 'error' event

Hi !
For the first time i'm facing a problem with EE2, here is the code:
let net = require('net')
let ev = require('eventemitter2').EventEmitter2
let myProject = function(host, port) {
  ev.call(this)
  let self = this
  let socket = net.connect(port, host)
  socket.on("error", function(e) {
    // here
    self.emit("error", "Socket", e.syscall + ' ' + e.errno + ' on ' + e.host + ':' + e.port)
  })
util.inherits(myProject, ev)
exports = module.exports = myProject

Each time i got this error Uncaught, unspecified 'error' event, when i change the event name for any other name the event is correctly emitted.
I don't understand why i have this behavior, this kind of feature works on any other components of my project.

Could you please post the stack trace from the error as well as the version of EE2 you have installed?

It seems that if you are not listening on the error event when it is emitted EvenEmmiter will throw this error.
The error can be reproduced like this
const EventEmitter2 = require('eventemitter2').EventEmitter2;
const events = new EventEmitter2();

console.log('sending first error event');
try {
  events.emit('error', 'The error data');
} catch(e) {
  console.log('caught error', e);
}

events.on('error', (error) => { console.log('got error event', error); });
console.log('sending second error event');
try {
  events.emit('error', 'The error data');
} catch(e) {
  console.log('caught error', e);
}

sending first error event
caught error Error: Uncaught, unspecified 'error' event.
    at EventEmitter.emit (/home/agirorn/code/test/node_modules/eventemitter2/lib/eventemitter2.js:398:15)
    at Object.<anonymous> (/home/agirorn/code/test/t.js:6:10)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:383:7)
    at startup (bootstrap_node.js:149:9)
sending second error event
got error event The error data

Thanks for the details, sadly I'm a bit busy at the moment, but a PR seems like it wouldn't be too hard to do and would be very much welcome!

I think think this is a similar case to the uncaught promise exception. When it occurs in node.js it is output to the console and the unhandledRejection event is sent. Could this be similar and somehow use the node.js process.on('warning', cb) Event: 'warning' to notify that this occurred and not throw an error that may end up killing the process?
I checked in node 6.12.0 and the process object is an event emitter object and can be used to do this.
process.on('warning', (m) => console.log(`got warning ${m}`));
process.emit('warning', 'test')
=> got warning test
=> true

Would that be an acceptable solution to this?

authors: RangerMauve agirorn antoine-pous

license: mit

license_source: bigquery


text:
error in import datetimepicker from eonasdan-bootstrap-datetimepicker

It is not  run directly by same as code in new ng 2 app which is build by CLI
We need to give full path
like
import { A2Edatetimepicker } from 'ng2-eonasdan-datetimepicker/src/datetimepicker.module';
import { DateTimePickerDirective } from 'ng2-eonasdan-datetimepicker/src/datetimepicker.directive';
When adding
import datetimepicker from 'eonasdan-bootstrap-datetimepicker';
it gives error
Error in import datetimepicker from 'eonasdan-bootstrap-datetimepicker';
So how we can import in our application
We have not file system.js and other directly app.module.ts

I think it is fixed with #27 and #31

authors: anksuthar atais


text:
🛑 Wedding HTTPS is down

In 31f143e, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in a00bfbe.

repo: atatkin/milos-uptime


text:
🛑 Wedding HTTPS is down

In 3286141, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in dc0c22b.


text:
🛑 Wedding HTTPS is down

In e0b5673, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 7390569.


text:
🛑 Wedding HTTPS is down

In c0d8034, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 9a9ed32.


text:
🛑 Wedding HTTPS is down

In 1ae00a5, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 31adf17.


text:
🛑 Wedding HTTPS is down

In b761869, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in f06af54.


text:
🛑 Minted HTTP is down

In d3631be, Minted HTTP ($MINTEDHTTP) was down:

HTTP code: 502
Response time: 393 ms

Resolved: Minted HTTP is back up in 7598917.


text:
🛑 Wedding HTTPS is down

In cf94385, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 78ed872.


text:
Sudden errors started coming and Postal stopped working!

Following was the 'postal status' output for smtp which was failing and given below errors were being logged. To resolve, I had to stop Postal and manually issue 'postal run' command instead of postal start which gave the same issue everytime it was started. What could be the issue?
============================================
|| smtp
|| Quantity            1
|| Command             bundle exec rake postal:smtp_server
|| Respawning          5 every 3600 seconds
|| Restart mode        usr1
|| Log path            none specified
|| Address/Port        none
|| => smtp.1           Stopped                   pid:1664     respawns:5      port:-        tag:-
|| => smtp.4           Failed       06:10        pid:3553     respawns:5      port:-        tag:-
============================================
[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:152:in `invoke_task'
^[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in `block (2 levels) in top_level'
^[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in `each'
^[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in `block in top_level'
^[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:117:in `run_with_threads'
^[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:102:in `top_level'
^[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:80:in `block in run'
^[[34m[smtp.1:1282]^[[0m [2017-07-31T05:09:55.212] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:178:in `standard_exception_handling'
============================================
```

Not enough information there for us to debug that, I'm afraid.

Let me know what else would be required. Shared the /opt/postal/log/smtp_server.log and postal status right now.

Any update? Still only 'postal run' in screen is running but not postal start or postal stop and start :(

^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.111] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:187:in block in invoke_with_call_chain' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /usr/lib/ruby/2.3.0/monitor.rb:214:in mon_synchronize'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:180:in invoke_with_call_chain' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:173:in invoke'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:152:in invoke_task' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in block (2 levels) in top_level'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in each' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in block in top_level'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:117:in run_with_threads' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:102:in top_level'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:80:in block in run' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:178:in standard_exception_handling'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:77:in run' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/exe/rake:27:in <top (required)>'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/bin/rake:22:in load' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.114] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/bin/rake:22:in '
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : An error occurred while accepting a new client.
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : Errno::ENOTCONN: Transport endpoint is not connected - getpeername(2)
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/postal/smtp_server/server.rb:103:in remote_address' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/postal/smtp_server/server.rb:103:in block (2 levels) in run_event_loop'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/postal/smtp_server/server.rb:86:in select' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/postal/smtp_server/server.rb:86:in block in run_event_loop'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/postal/smtp_server/server.rb:84:in loop' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/postal/smtp_server/server.rb:84:in run_event_loop'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/postal/smtp_server/server.rb:259:in run' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/app/lib/tasks/postal.rake:13:in block (2 levels) in <top (required)>'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:248:in block in execute' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:243:in each'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:243:in execute' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:187:in block in invoke_with_call_chain'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /usr/lib/ruby/2.3.0/monitor.rb:214:in mon_synchronize' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:180:in invoke_with_call_chain'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:173:in invoke' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.115] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:152:in invoke_task'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in block (2 levels) in top_level' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in each'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in block in top_level' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:117:in run_with_threads'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:102:in top_level' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:80:in block in run'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:178:in standard_exception_handling' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:77:in run'
^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/exe/rake:27:in <top (required)>' ^[[34m[smtp.1:1282]^[[0m [2017-07-30T23:15:45.116] ERROR -- : /opt/postal/vendor/bundle/ruby/2.3.0/bin/rake:22:in load'

I have the same problem:
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : An error occurred while accepting a new client.
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : Errno::ENOTCONN: Transport endpoint is not connected - getpeername(2)
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/postal/smtp_server/server.rb:104:in `remote_address'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/postal/smtp_server/server.rb:104:in `block (2 levels) in run_event_loop'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/postal/smtp_server/server.rb:87:in `select'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/postal/smtp_server/server.rb:87:in `block in run_event_loop'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/postal/smtp_server/server.rb:85:in `loop'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/postal/smtp_server/server.rb:85:in `run_event_loop'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/postal/smtp_server/server.rb:260:in `run'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/lib/tasks/postal.rake:13:in `block (2 levels) in <top (required)>'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/task.rb:273:in `block in execute'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/task.rb:273:in `each'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/task.rb:273:in `execute'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/task.rb:214:in `block in invoke_with_call_chain'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /usr/local/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'
[smtp.1:70] [2020-12-01T20:21:42.238] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/task.rb:194:in `invoke_with_call_chain'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/task.rb:183:in `invoke'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:160:in `invoke_task'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:116:in `block (2 levels) in top_level'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:116:in `each'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:116:in `block in top_level'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:125:in `run_with_threads'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:110:in `top_level'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:83:in `block in run'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:186:in `standard_exception_handling'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/lib/rake/application.rb:80:in `run'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/gems/rake-12.3.2/exe/rake:27:in `<top (required)>'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/bin/rake:23:in `load'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /opt/postal/vendor/bundle/ruby/2.6.0/bin/rake:23:in `<top (required)>'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:74:in `load'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:74:in `kernel_load'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:28:in `run'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/cli.rb:463:in `exec'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
[smtp.1:70] [2020-12-01T20:21:42.239] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/cli.rb:27:in `dispatch'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/cli.rb:18:in `start'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.2/exe/bundle:30:in `block in <top (required)>'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/lib/ruby/2.6.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.2/exe/bundle:22:in `<top (required)>'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/bundle/bin/bundle:23:in `load'
[smtp.1:70] [2020-12-01T20:21:42.240] ERROR -- : /usr/local/bundle/bin/bundle:23:in `<main>'

authors: adamcooke cinco webhostinggeek

repo: atech/postal


text:
new user

Hi,
How we can create user and  assigned to a organization?
In above of create a user through web UI, it show:

To add someone to your organization enter their e-mail address below. If they don't already have a Postal account, they'll need to create one before you can add them to your account.

where we should create users? how they can create account? through cli?

Firstly, make sure you have configured a way for Postal to send emails in your postal.yml config file.
Then if you want a user to access only one organization or only one server in an organization, use the form to send them an email.
If you want a user to access all organizations, you will need to use the postal make-user command in your terminal.

i added smtp connection but app emails not sent?

You'll have to look in the logs to see what is happening I'm afraid.


text:
Support a site icon

Replace the GitHub icon with a user-defined site icon if set.

This should be called "logo" to support SEO integration

repo: athackst/jekyll-theme-profile


text:
templates: fix indentation in SASS component

This fixes the following build error
ERROR in ./source/index.sass
Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
SassError: Illegal nesting: Only properties may be nested beneath properties.
        on line 14 of source/components/app.sass
>>                      .title {

   ---^

Oops, didn't see that. Thanks :)


text:
Create a Mongodb docker container for LC

Created by Luis Marin Vera via monday.com integration. 🎉

Mongodb docker container for LC #70 created #3992936952 epic_data_persistency epic_topo_update


text:
configure communication between API and client

The client and API should be served by separate services (potentially two docker images). The frontend will need an API communication module added to it.

The client and API should be served by separate services (potentially two docker images).

We've been well-served by docker-for-backend/yarn-for-frontend; no need for dockerizing the frontend.

The frontend will need an API communication module added to it.

If you're describing a typescript file that encapsulates API calls, I can see that being useful, but I want to evaluate that in light of the frontend team's needs, so I'm going to close this issue.

authors: annehaley waxlamp

repo: atlascope/atlascope


text:
The value passed to --snapshot is not validated

Affected Packages

Problem

Make a snapshot release with a custom snapshot tag that is not a valid prerelease tag. For instance: changesets version --snapshot a_b
The versions will be update to 0.0.0-a_b-<timestamp>. However, publishing will fail because versions cannot contain a _ char.
Proposed solution

There are two possible solutions:

fail with a meaningfull error when --shapshot gets an invalida prerelease tag (semver.valid may be used for validation)
try to make the passed value valid. Convert invlid chars to -, make all characters lower case, etc.

I would be in favor of the first proposed solution. Do you have any good references for which characters are allowed and which are not?

If I understand correctly from the source of semver:

it may contain upper and lower case Latin letters
numbers
dashes
a single dot

As I mentioned, semver.valid may be used to validate the version.

authors: Andarist zkochan

repo: atlassian/changesets


text:
feat: Added support for configuring healthcheckPath to Synchrony readinessProbe

Pull request description
When setting up my external Google Cloud Ingress (not using Nginx Ingress), we need the ability to configure the healthcheck path. As documented, Synchrony expects the path to include "/synchrony" to be included in all requests. If not, we were seeing healthchecks returning back a 204 No Content.
Checklist

[ ] I have added unit tests
[ ] I have applied the change to all applicable products
[ ] I have added the change description to the changelog.md and Chart.yaml files
[ ] (Atlassian only) I have run the E2E test (if applicable)
[ ] (Atlassian only) Internal Bamboo CI is passing

@jvasallo I am struggling to understand in which scenario you would want to change path for httpGet in the probe config. Would't it fails if it's anything but /heartbeat? Kubelet will use internal IP to run the requests, i.e. ingress isn't involved

@bianchi2 Google Cloud Ingresses by default look at the readiness probe and use that as the interpreted healthcheck:
https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#interpreted_hc
My solution was to retain the existing default path (/heartbeat), whilst allowing me to customize it to the true working path (/synchrony/heartbeat). I was hoping this would spawn a conversation on the default HC path as I am not sure how it ever worked...yet folks on the Atlassian forums seem to claim it does.
I can revert my changes (and hardcode the path) or allow users to specify the path. It could be helpful if folks front Syncronchy or need to tweak it at all in the java settings.

@jvasallo , thank you for the contribution. I think this change is useful and regardless of the k8s documentation about the acceptance result for health check, this is an improvement. WDYT @bianchi2?

@jvasallo can you please make the default /synchrony/heartbeat since this is the path that returns 200. Once done, I am happy to merge :)

@bianchi2 In terms of implementation, would you rather:

Retain the ability to override HC Path in Helm Value
Fix the path in the template, revert Helm Value adds.

I am leaning towards option 2 as it's more inline with the rest of the project but happy to keep changes I originally proposed :)

In fact, I'm ok with keeping it as is - having default in values and making it possible to override.
Also, could you please fix unit tests by changing path here too? https://github.com/atlassian/data-center-helm-charts/blob/main/src/test/resources/expected_helm_output/confluence/output.yaml#L167

Awesome and thank you. Hours didn't align for me to fix it, but was about to this morning. Let me know if you need anything else from me and thank you!

authors: bianchi2 jvasallo nghazali

repo: atlassian/data-center-helm-charts


text:
Atom Crashes on Ubuntu 16.04 LTS when init.coffee is open

Prerequisites

[X] Can you reproduce the problem in safe mode?
[X] Are you running the latest version of Atom?
[X] Did you check the debugging guide?
[X] Did you check the FAQs on Discuss?
[X] Are you reporting to the correct repository?
[X] Did you perform a cursory search to see if your bug or enhancement is already reported?

For more information on how to write a good bug report or enhancement request, see the CONTRIBUTING guide.
Description
The Atom editor crashes when trying to close a previously opened init.coffee
Steps to Reproduce

open init.coffee
Make sure Open empty editor in settings is not checked.
close atom, but don't close the init.coffee tab.
when you open atom again, try and close init.coffee script.
at this point atom crashes immediately.

Note
I did solve the issue by opening atom with the --clear-window-state flag this loaded an empty atom editor and everything works normally, but when I try to open init.coffee the same behaviour is back.
Also, i have nothing in my init.coffee script.
Versions
atom : 1.10.2
Electron : 0.37.8
Chrome : 49.0.2623.75
Node : 5.10.0
apm : 1.12.5

I'll see if I can reproduce this on my PC running the same version of Ubuntu.

The very first time Atom crashed when I closed Atom with the init.coffee script open. After that it hasn't crashed with the exact steps mentioned. So it was reproducible but only once.

Excatly same problem on Fedora 24.
Atom    : 1.10.2
Electron: 0.37.8
Chrome  : 49.0.2623.75
Node    : 5.10.0
apm : 1.12.5

Same problem on kali linux, it happens also with the style.less file

Similar problem on windows 7.  Atom loads with the tab, init.coffee open and crashes when trying to close the file.

Same problem on Windows 10.

Problem still exists on Windows 7. Deleting it also doesn't cause it to regenerate from the .atom folder, as config.cson normally regenerates upon deletion.

same problem when trying to close tab with init.coffee. Ubuntu 16.04 / Atom 1.12.6

Same problem
windows 10
atom 1.12.7
To resolve: I uninstalled atom and then deleted .atom file under my user name

Same behavior on OS X, Sierra, atom 1.12.9

Duplicated on OS X, Sierra, Atom 1.13.1 x64

repo: atom/atom


text:
Blurry text on Windows 10

Prerequisites

[x] Can you reproduce the problem in safe mode?
[x] Are you running the latest version of Atom?
[x] Did you check the debugging guide?
[x] Did you check the FAQs on Discuss?
[x] Are you reporting to the correct repository?
[x] Did you perform a cursory search to see if your bug or enhancement is already reported?

For more information on how to write a good bug report or enhancement request, see the CONTRIBUTING guide.
Description
Hello, I'm having issues with font rendering on Windows 10 since a while now. I've already tried to fix it with CSS and adjust the ClearType text, but nothing happened. My screen resolution is 1366x768.
When I click somewhere on the screen, the font goes back to normal for a few seconds, then slowly blurs back again (as you can see below). It would be nice to fix this, I'm sticking to Sublime Text until I find a solution. Thanks in advance.

Steps to Reproduce

When opening Atom
When typing something

Expected behavior: The font should be sharp as below (print from Sublime Text):

Actual behavior: Everything looks blurry.
Versions
You can get this information from executing atom --version and apm --version at the command line. Also, please include the OS and what version of the OS you're running.
Atom    : 1.12.5
Electron: 1.3.9
Chrome  : 52.0.2743.82
Node    : 6.5.0

apm  1.12.9

@in-dex could you also launch Command Prompt and see what build of Windows 10 you're running?

Also what graphics chip and driver you are using and whether you get any odd font issues in Chrome.

@shiftkey

I believe this is a duplicate of #12652, no?

I don't think it is - the other one is losing subpixel AA. This one appears to be more of a bad transform happening and somehow 'eroding' the text.

I personally suspect it's a bad video driver or a graphics profile setting intended for games getting applied to Atom by mistake.

Not able to repro with stock Atom 1.12.6 on the closest machine I have - Intel HD Graphics 520 with drivers 20.19.15.4463

Can you include a screenshot of the blurry text while running atom --safe ?

@damieng I finally fixed it! You were right, the problem was the sharpness settings on the Intel Graphics Panel (even though I never opened it), it also fixed the same problem on Visual Studio Code and Visual Studio 2016.

Thanks for figuring that out - I'm sure this thread will be useful to other people too running into this. Not many apps take advantage of HW accelerated rendering yet so I'm sure Intel have some work to do in figuring out when to turn this on (although in my mind that would be never ;-) )

@c0imbra  I can't find any sharpness settings in Intel HD graphics panel.  can you please tell me where can I find this option.

The issue for most, if not all, is with the graphics card options software, which also explains why this only occurs on Windows and not Linux.
I was able to fix this by setting the following:

Intel HD Graphics Control Panel

3D:

Application Optimal Mode: Disable
Multi-Sample Anti-Aliasing: Disable


text:
We are

Prerequisites

[ ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

Steps to Reproduce

Expected behavior:

Actual behavior:

Reproduces how often:

Versions

Additional Information

Thanks for reaching out!
We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us half way :grinning:


text:
Node package exhibits odd, Windows-specific file system permissions issues when running inside Atom package

My package has a dependency that does some file system interaction, in this case, streaming a base64 encoded zip file to the file system. I'm the author of the package dependency as well. The code below (from the Atom package dependency) passes in tests on Linux, Unix, and Windows and works fine when used by my Atom package in Linux and Unix. However, when running in Atom on Windows, this code produces an Administrator-owned, read-only zip file that I can't seem to delete, even via the UI. What's odd to me is fs.removeSync does not throw an exception. I'm posting here because I've spent a lot of time determining whether this is Atom-specific behavior and I've come to the conclusion that it seems to be. Any idea why this may be occurring?
var zipStream = new Stream();
zipStream.readable = true;
zipStream.emit('data', new Buffer(result.zipFile, 'base64'));
zipStream.emit('end');

zipStream.pipe(fstream.Writer('/path/to/zipfile.zip'))
  .on('close', function() {
    var zip = new AdmZip('/path/to/zipfile.zip');
    zip.extractAllTo('/path/to');
    fs.removeSync('/path/to/zipfile.zip');
    resolve();
  });

@50Wliu @benogle Any movement on this bug?
@joeferraro hope the atom team fixes this issue so that we can enjoy using your Salesforce atom plugin.
The last comment on this thread from atom team is in Feb.
Thank you guys for a wonderful editor and @joeferraro for his mighty plugins.
Thanks.

I'm not sure. This seems like a node bug. Can you reproduce this outside of atom? Just a regular node script?

@joeferraro Is it possible for your to reproduce this error out side atom as requested by @benogle?
We are really looking forward to using atom and mavensmate from our win 7 environments.
Thanks.

@benogle that's the problem, we're unable to reproduce outside Atom. Our appveyor/circleci tests for the node dependency in question (https://github.com/joeferraro/MavensMate) pass with no issue and this library also powers our Sublime Text plugin without issue.
It's also worth noting that the Atom tree-view has a rather odd impact on perms in Windows (https://github.com/atom/tree-view/issues/436#issuecomment-105624411).
For the time being, we're moving certain operations that we deem to be file system "heavy lifting" (excuse the term, it's just that node has so many problems with windows that even renaming a directory becomes a cautionary tale) to the system shell in an effort to workaround these issues in Atom.

I think I just encountered this issue but Atom was not the one that created the folder. I had a folder that  was created by a gulp task (gulp-msbuild). I found that it said that I had no permissions to delete that folder until I closed Atom. Then it allowed me to delete the folder.
I'll compile a better detailed report on the specific case I'm seeing and hopefully a way to reproduce it.

Would love to start using Atom instead of Sublime for Salesforce/MavensMate development! Let me know if there's anything I can do to help.
Additionally if there's a technical workaround I'm totally ok with that.

We're eagerly awaiting a fix for this issue, as we would very much like to switch our Salesforce development to Atom, away from Sublime.

authors: benogle cnaccio joanbarros joeferraro pjcarly venkatpolisetti


text:
Menu.remove ?

How are we currently supposed to remove a menu entry, i.e. when we're adding & removing views? There seems to be an append() and insert() api on Menu only, no remove?

Well since we all known Chromium have this limitation, I found a way to work around with this. I paste my code here so that people can follow the way to get around it.
My solution is to rebuild the menu except the item you specified by path. Let's say, you have a menu item  in the menu path: foo/bar/foobar, and when you run Editor.MainMenu.remove('foo/bar/foobar'), it will clone the exists Menu, except the one you want to removed.
The code to do this:
var Path = require('fire-path');
var Editor = require('fire-editor')
var Editor.JS = require('js-utils');

function _cloneMenuItemLevel1 ( menuItem ) {
    var options = Editor.JS.extract( menuItem, [
        'click',
        'selector',
        'type',
        'label',
        'sublabel',
        'accelerator',
        'icon',
        'enabled',
        'visible',
        'checked',
        // 'submenu', // NOTE: never clone submenu, other wise we can't change item inside it
        'id',
        'position',
    ]);
    if ( options.type === 'submenu' ) {
        options.submenu = new Menu();
    }
    return new MenuItem(options);
}

function _cloneMenuExcept ( newMenu, nativeMenu, exceptPath, curPath ) {
    var result = false;

    for ( var i = 0; i < nativeMenu.items.length; ++i ) {
        var menuItem = nativeMenu.items[i];
        var path = Path.join( curPath, menuItem.label );

        if ( Path.contains( path, exceptPath ) ) {
            if ( path === exceptPath ) {
                result = true;
                continue;
            }

            var newMenuItem = _cloneMenuItemLevel1(menuItem);
            if ( newMenuItem.type === 'submenu' ) {
                var removed = _cloneMenuExcept( newMenuItem.submenu,
                                                menuItem.submenu,
                                                exceptPath,
                                                path );
                if ( removed ) result = removed;
            }
            newMenu.append(newMenuItem);
        }
        else {
            newMenu.append(menuItem);
        }
    }

    return result;
}

// base on electron#527 said, there is no simple way to remove menu item
// https://github.com/atom/electron/issues/527
MainMenu.remove = function ( path ) {
    var newMenu = new Menu();
    var removed = _cloneMenuExcept( newMenu, this.nativeMenu, path, '' );

    if ( !removed ) {
        Editor.error('Failed to remove menu in path: %s, can not find it', path );
        return false;
    }

    // apply to main menu
    Menu.setApplicationMenu(newMenu);

    return true;
};

The 'fire-path' is just a io.js path module with Path.contains( pathA, pathB ) support, which used in above code, I put the implementation below. And the Editor.JS.extract is just a easy function to copy the properties you want from the oldMenuItem, so I guess you can modify it to your own.
// pathA = foo/bar,         pathB = foo/bar/foobar, return true
// pathA = foo/bar,         pathB = foo/bar,        return true
// pathA = foo/bar/foobar,  pathB = foo/bar,        return false
// pathA = foo/bar/foobar,  pathB = foobar/bar/foo, return false
FirePath.contains = function ( pathA, pathB ) {
    pathA = FirePath.stripSep(pathA);
    pathB = FirePath.stripSep(pathB);

    //
    if ( pathA === pathB ) {
        return true;
    }

    // never compare files
    if ( Path.dirname(pathA) === Path.dirname(pathB) ) {
        return false;
    }

    if ( pathA.length < pathB.length &&
         pathB.indexOf (pathA) === 0 )
    {
        return true;
    }

    return false;
};

I test these in my editor-framework for a couple of days, and it works well, hope this can help you.

I recently spent a lot of time investigating this and found a solution that worked for me.  For our project, we have menus like:

File
Edit
etc (none of these change)

and menus which do change:

History
Bookmarks

Here's how I solved it for us:

Use the current menu handle and find the MenuItem object for the parent menu (ex: History)
Note that MenuItem has a submenu object, which is also of type menu
Call clear() on that submenu
Re-add the child menu items using submenu.append()
Call Menu.setApplicationMenu with your modified top-level menu handle

This seems to work great (you can check the change out here).
My only concern is that it may leak memory.  I did some basic profiling by attaching to the process (with a version of Electron w/ symbols) and object counts seemed to be OK. Comments or concerns appreciated :smile:
One route I tried, which did not work, was exposing the RemoveItemAt method of the underlying model. When you call this, it does remove the item from the menu that's visible to the user... but not from the menu object itself. On top of that, even if you call destroy on the MenuItem's submenu, it visibly leaks memory.  I can see why @zcbenz said this is a limitation of Chromium

@bsclifton I think the work around works pretty well, except for one thing.
I'm not sure if you noticed, the menu.items gets accumulated, even menu.clear() has been called.

authors: bsclifton jwu quasado yunjia

repo: atom/electron


text:
Run tests on Appveyor

We have bought its paid plan, each test takes about 10min to run, not very fast but better than travis ci's mac machine.

:+1: awesome

authors: etiktin zcbenz


text:
Multi-container pod tailing, duplicate tails fixes

Despite PR #17, the current main can still duplicate container tails. That PR also introduced a regression that causes only one container to be tailed from a pod with multiple containers.
Repro - note that you may need to update the stateful set multiple times as the duplicate tailing doesn't necessarily occur every time:

Start ktail:

[ktail (main-)]$ ktail -lapp ktail-test --timestamps

Apply the following stateful set:

[ktail (main-)]$ kubectl apply -f -
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: ktail-test
spec:
  selector:
    matchLabels:
      app: ktail-test
  serviceName: ktail-test
  replicas: 1
  template:
    metadata:
      labels:
        app: ktail-test
      annotations:
        foo: a
    spec:
      containers:
      - name: c1
        image: bash:latest
        command:
          - bash
          - -c
          - "x=1; while true; do echo $x; x=$((x+1)); sleep 1; done"
      - name: c2
        image: bash:latest
        command:
          - bash
          - -c
          - "x=1; while true; do echo $x; x=$((x+1)); sleep 1; done"
statefulset.apps/ktail-test created

Observe that only one of the containers is tailed:

[ktail (main-)]$ ktail -lapp ktail-test --timestamps
==> New container [ktail-test-0:c1]
==> New container [ktail-test-0:c2]
==> New container [ktail-test-0:c1]
2022-07-31 18:44:56.137848218 +0000 UTC ktail-test-0:c1 1
2022-07-31 18:44:57.139114374 +0000 UTC ktail-test-0:c1 2
2022-07-31 18:44:58.140316102 +0000 UTC ktail-test-0:c1 3
2022-07-31 18:44:59.141517492 +0000 UTC ktail-test-0:c1 4
2022-07-31 18:45:00.142660184 +0000 UTC ktail-test-0:c1 5
2022-07-31 18:45:01.143851672 +0000 UTC ktail-test-0:c1 6
2022-07-31 18:45:02.144969138 +0000 UTC ktail-test-0:c1 7
2022-07-31 18:45:03.146063988 +0000 UTC ktail-test-0:c1 8
2022-07-31 18:45:04.147207492 +0000 UTC ktail-test-0:c1 9
2022-07-31 18:45:05.148722608 +0000 UTC ktail-test-0:c1 10

Apply the stateful set again with an altered the foo annotation value:

[ktail (main-)]$ kubectl apply -f -
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: ktail-test
spec:
  selector:
    matchLabels:
      app: ktail-test
  serviceName: ktail-test
  replicas: 1
  template:
    metadata:
      labels:
        app: ktail-test
      annotations:
        foo: b
    spec:
      containers:
      - name: c1
        image: bash:latest
        command:
          - bash
          - -c
          - "x=1; while true; do echo $x; x=$((x+1)); sleep 1; done"
      - name: c2
        image: bash:latest
        command:
          - bash
          - -c
          - "x=1; while true; do echo $x; x=$((x+1)); sleep 1; done"
statefulset.apps/ktail-test configured

Observe two tails occurring for the one container that is being tailed.

2022-07-31 18:50:18.37143432 +0000 UTC ktail-test-0:c1 158
2022-07-31 18:50:19.3726387 +0000 UTC ktail-test-0:c1 159
2022-07-31 18:50:20.373825931 +0000 UTC ktail-test-0:c1 160
2022-07-31 18:50:21.375127732 +0000 UTC ktail-test-0:c1 161
==> Container left (waiting) [ktail-test-0:c1]
==> New container [ktail-test-0:c1]
==> New container [ktail-test-0:c2]
==> New container [ktail-test-0:c1]
2022-07-31 18:50:25.302927917 +0000 UTC ktail-test-0:c1 1
2022-07-31 18:50:26.304258933 +0000 UTC ktail-test-0:c1 2
2022-07-31 18:50:25.302927917 +0000 UTC ktail-test-0:c1 1
2022-07-31 18:50:26.304258933 +0000 UTC ktail-test-0:c1 2
2022-07-31 18:50:27.305345594 +0000 UTC ktail-test-0:c1 3
2022-07-31 18:50:27.305345594 +0000 UTC ktail-test-0:c1 3
2022-07-31 18:50:28.306654222 +0000 UTC ktail-test-0:c1 4
2022-07-31 18:50:28.306654222 +0000 UTC ktail-test-0:c1 4
2022-07-31 18:50:29.307982535 +0000 UTC ktail-test-0:c1 5
2022-07-31 18:50:29.307982535 +0000 UTC ktail-test-0:c1 5
2022-07-31 18:50:30.309096542 +0000 UTC ktail-test-0:c1 6
2022-07-31 18:50:30.309096542 +0000 UTC ktail-test-0:c1 6
2022-07-31 18:50:31.310262842 +0000 UTC ktail-test-0:c1 7
2022-07-31 18:50:31.310262842 +0000 UTC ktail-test-0:c1 7
2022-07-31 18:50:32.311563671 +0000 UTC ktail-test-0:c1 8
2022-07-31 18:50:32.311563671 +0000 UTC ktail-test-0:c1 8
2022-07-31 18:50:33.312661348 +0000 UTC ktail-test-0:c1 9
2022-07-31 18:50:33.312661348 +0000 UTC ktail-test-0:c1 9
2022-07-31 18:50:34.313957002 +0000 UTC ktail-test-0:c1 10
2022-07-31 18:50:34.313957002 +0000 UTC ktail-test-0:c1 10

I believe this PR fixes both of the above issues, as well as issue #18.
Context for the changes:

Prior to #17 the tailer key differentiated by container ID, but that is not always populated, and thus could result in duplicate container tails. As such, the container ID was removed from the tailer key. However, that meant that only one container per pod could be tailed.
https://github.com/atombender/ktail/commit/8623cabc1acb4b0ed52e51e0bd6390ab0d03a80d updates the tail key to differentiate by container name to allow for multiple containers per pod to be tailed without the issue of container ID sometimes not being populated. I believe using container name should be sufficient.

In my debugging, I observed that in the tailer runStream loop, EOF may be read before Stop is called and before current Run loop calls runStream. In that case we may get a duplicate tail as the controller may have initiated a new tail, but the existing runStream loop would continue indefinitely.
https://github.com/atombender/ktail/commit/f917806999776a1bccf6141a45d6ece60364a8e1 adds a check to the runStream loop to see if the controller has attempted to stop the given tailer.

Awesome, thank you! I'm on vacation right now, but will look as soon as I have a chance.

authors: atombender schellj

repo: atombender/ktail


text:
:speech_balloon: 讨论关于聊天栏显示最新的一句话。

显示整个会话中最新的一条。
显示整个会话中其他人发送的最新的一条。

@DesignerLookMe @liuwj-java

已实现

repo: atomicCoke/chat