[BUG] Collector: Error initializing Python: GLIBC_2.25 not found. Agent_version: 7.39.1 on RHEL7 aarch64

[BUG] Collector: Error initializing Python: GLIBC_2.25 not found. Agent_version: 7.39.1 on RHEL7 aarch64
Agent Environment

(See below for details)
Describe what happened:
Running datadog-agent status shows that the checks collector is unable to run.
Describe what you expected:
I expect for the datadog custom checks functionality to be working OK.
Steps to reproduce the issue:
Install and run this version of datadog agent on this server architecture.
Additional environment details (Operating System, Cloud provider, etc):
(See below)
===============
Agent (v7.39.1)
===============

  Status date: 2022-10-11 22:18:51.386 GMT<PHONE_NUMBER>386)
  Agent start: 2022-10-11 21:46:17.786 GMT<PHONE_NUMBER>786)
  Pid: 1663
  Go Version: go1.17.11
  Python Version: n/a
  Build arch: arm64
  Agent flavor: agent
  Check Runners: 5
  Log Level: INFO

Host Info
  =========
    bootTime: 2022-10-11 21:46:06 GMT<PHONE_NUMBER>000)
    hostId: e66936d9-190e-4784-90f4-14b2febf39a3
    kernelArch: aarch64
    kernelVersion: 5.4.17-2136.311.6.1.el7uek.aarch64
    os: linux
    platform: oracle
    platformFamily: rhel
    platformVersion: 7.9
    procs: 187
    uptime: 18s
    virtualizationRole: guest

Metadata
  ========
    agent_version: 7.39.1
    cloud_provider: Oracle
    install_method_installer_version: datadog_role-4.15.0
    install_method_tool: ansible
    install_method_tool_version: ansible-2.12.5

=========
Collector
=========
  Error initializing Python
  =========================
    - could not load runtime python for version 3: Unable to open three library: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /opt/datadog-agent/embedded/lib/libpython3.8.so.1.0)

$ ldd --version && uname -a
ldd (GNU libc) 2.17
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
Linux kafka-01 5.4.17-2136.311.6.1.el7uek.aarch64 #2 SMP Thu Sep 22 19:41:24 PDT 2022 aarch64 aarch64 aarch64 GNU/Linux

2022-10-07 00:43:50 GMT | CORE | INFO | (pkg/collector/python/init.go:322 in resolvePythonExecPath) | Using '/o
pt/datadog-agent/embedded' as Python home
2022-10-07 00:43:50 GMT | CORE | INFO | (pkg/collector/python/init.go:389 in Initialize) | Initializing rtloade
r with Python 3 /opt/datadog-agent/embedded
2022-10-07 00:43:50 GMT | CORE | ERROR | (pkg/collector/embed_python.go:19 in pySetup) | Could not initialize Python: could not load runtime python for version 3: Unable to open three library: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /opt/datadog-agent/embedded/lib/libpython3.8.so.1.0)

Hi!
Thanks for the detailed report! Can we get a few more details about how the agent was installed? If you could give the specific package that was installed by ansible (and which package version) that would be helpful.
Additionally could you run objdump -T /opt/datadog-agent/embedded/lib/libpython3.8.so.1.0 | grep GLIBC_ | head and put the output here?
Thanks!

After some more discussion with the team, this is expected for rpm packages on aarch64, our minimum supported glibc version for aarch64 rpm is 2.26. We'll be adding better documentation around glibc versioning so this is more discoverable.
If you'd like to support run on older glibc versions on aarch64 please reach out to support so we can get a feature request created.
Closing this for now as expected behavior.


go/mysql: conn: Add LoadInfile method which returns a ReadCloser for reading the remote file from a client.

We will migrate the implementation in go-mysql-server from HandleLoadDataLocalQuery to this interface. This keeps the responsibility for writing the file and the likes out of the vitess/conn layer.

You can see how this is used here: https://github.com/dolthub/go-mysql-server/pull/684
For now HandleLoadDataLocalQuery is left in place so as to not break the go-mysql-server build. We will remove it once go-mysql-server updates to the new method.


Fix issue with receiving the first chunk with an empty list of choices

EPAM AI DIAL chat version
0.6.19
What happened?
Fixes issue with receiving the first chunk with an empty list of choices
Confidential information

[X] I confirm that do not share any confidential information

Verified on staging env that GPT-3.5 models (all versions) respond ok, work with addons and react according to system prompt set.


Cleanup README.md removing reference to resetOffset and reduce references to iCub

Sorry for the big cleanup PR, but I do not think the additional time spent in splitting the changes in multiple commits was worth it.
Main changes:

Drop the instructions to run resetOffset after wholebodydynamics is launched, this is not necessary since https://github.com/robotology/whole-body-estimators/pull/72 and https://github.com/robotology/whole-body-estimators/issues/67
Remove a lot of references to iCub robot as at the moment the software is mainly working on ergoCub

fyi @xela-95 @GiulioRomualdi @S-Dafarra @loremoretti

Thank you @traversaro


How to visualize the generated dance motion with the API?

Hi ruilong, I'm trying the visualize the test result from the trained MINT model, I try to run the following demo code and the output is a freezing image like below.

Could you tell me is there a code to visualize(render) the generated dance output to a video like the videos provided in theoverview of AIST++? Thank you so much.

Hi!
The API by default only visualize the first frame on the mesh to allow user interaction (rotating etc). Please check the code here: https://github.com/google/aistplusplus_api/blob/5a20b5f193c5b279461f9e123aa5c1fe6ec7c736/demos/run_vis.py#L96-L110
The easiest way to visualize the whole sequence is to do a for loop like this:
vertices = smpl.forward(
    global_orient=torch.from_numpy(smpl_poses[:, 0:1]).float(),
    body_pose=torch.from_numpy(smpl_poses[:, 1:]).float(),
    transl=torch.from_numpy(smpl_trans).float(),
    scaling=torch.from_numpy(smpl_scaling.reshape(1, 1)).float(),
    ).vertices.detach().numpy()
faces = smpl.faces

for verts in vertices:
  mesh = trimesh.Trimesh(verts, faces)
  mesh.visual.face_colors = [200, 200, 250, 100]
  vedo.show(mesh, interactive=False)

Unfortunately in our video we use blender and some other tools for visualization so we didn't release those in the repo. It's above lines should be a start for you to visualize the mesh!
Thanks


Consolidate Kafka packages into one single package

These 2 packages pkg/reconciler/kafka and pkg/kafka always
confuse me about their purpose, so I think it makes more sense to
keep one single package for "Kafka" related functions.
Signed-off-by: Pierangelo Di Pilato<EMAIL_ADDRESS>

/cc @devguyio @matzew @aliok

will take a :eye:
/assign


Update MinGW to 12.2

Tool name
MinGW
Tool license
GNU
Add or update?

[ ] Add
[X] Update

Desired version
12.2
Approximate size
No response
Brief description of tool
No response
URL for tool's homepage
No response
Provide a basic test case to validate the tool's functionality.
No response
Platforms where you need the tool

[ ] Azure DevOps
[X] GitHub Actions

Runner images where you need the tool

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] Windows Server 2019
[X] Windows Server 2022

Can this tool be installed during the build?
choco install mingw

Tool installation time in runtime
No response
Are you willing to submit a PR?
No response

Hello @quyykk, we will have a look

Will be deployed next week.

Deployed

@mikhailkoliada I was wondering if this is worthy of the Announcement label as many other similar changes to tool versions get such an announcement label. In particular this update changed the major version of gcc from 11.2 to 12.2 and related toolchain items.

Yup, this has led to my CI pipeline failing... This definitely needs added to the announcements.

This is also causing me a lot of headaches since the update seems to also change what implementation of LibC it is using. Linking against precompiled MinGW binaries is now failing and even when I'm not doing that, I can't run any unit tests built using MinGW because they fail to start up due to what I believe are missing DLLs.


Added fix to shorten temp file name when on windows which has issues …

…with long file paths.
Adding 33 characters to the end of a file greatly increase the chances of rename errors being thrown in the win32 api.

I'm not comfortable with this patch as it changes the semantics of getTmpname. It's supposed to guarantee a unique filename, across multiple simultaneous processes and simultaneous invocations of writeFile. With this patch, on Windows, it would do none of that.
An alternative would be to append .write-file-atomic.$PID.$INVOCATIONS (or something equivalent to that). That'd reduce the amount appended to between 13 and 27 characters, instead of 32. I'm wondering how much that would help though. =/  Maybe ditch the filename part? eg, use .$MD5 as the filename?

I'm going to close this, but I would be open to an updated PR that maintains the same level of uniqueness we currently have.


Any plan to support new version of VRM?

このリポジトリはVRM 0.xに対応していてVRM 1.0には対応していないようです。
VRM 1.0に対応する予定はありますか?

Issueありがとうございます！
VRM 1.0に対応するモチベーションはありますが、現在対応するための時間がなく、対応できていません。
VRM 1.0対応のpull requestは受け付けています。
[en]
Thank you for this issue!
I'm motivated to support VRM 1.0, but currently don't have the time to provide the support.
I welcome pull requests for VRM 1.0 support.

ありがとうございます。実装と仕様書を理解してみて、行けそうならPull Requestを送ります。

VRM 1.0 レンダリングは現在主流ですか? そうでない場合、その必要性は何ですか? レンダリングはできず、「分析」することしかできないようですが?
Is Rendering VRM 1.0 a thing now? If not, what is needed? I see that only "parsing" is possible, but not rendering them?

@c4b4d4
Yes, VRM 1.0 is becoming mainstream, but VRM 0.x models are still widely used.
To render VRM 1.0, it's necessary to adapt the parsed results to the rendering system of Apple platforms (SceneKit), which will take lots of time to support.
Currently, VRMKit is in the middle of supporting VRM 1.0.

Thank you for your interest!
I'm currently busy with my main job, so I haven't been able to start working on this myself. I'm sorry.
The most challenging part is mapping the parsed data to the various classes in SceneKit.
The most important task is to make it possible to create a VRMNode by passing a VRM1 object, as it is currently feasible to load a VRM as a VRMNode. Modifying this part requires changing many affected codes.
https://github.com/tattn/VRMKit/blob/f45e1ea/Sources/VRMSceneKit/VRMSceneLoader.swift#L36
VRM refers to VRM 0.x model data, and VRM1 refers to VRM 1.x model data.

Hi, @c4b4d4 . Actually, I have successfully rendered a VRM 1.0 file. But I haven't sent a pull request because my implementation has some shortcomings.
https://github.com/is0263rf/VRMKit/tree/development
For example, I haven't implemented Expression (BlendShape).
https://vrm.dev/vrm1/expression/
I don't know if my implementation will be useful to you. I look forward to your pull request to the tattn's repository.


Been getting following error Post -url-: EOF

Has anyone seen this kind of error before? I ran this client on a loop for the last 12 hours, and around once every hour i noticed this error. It did not return any other contextual information

This is probably way too late to be useful to you, but I was seeing a similar issue. It boiled down to the sender (client) expecting the recipient to close the connection by default which it wasn't doing.
Adding the "ImmediatelyCloseReqBody" flag to the client instantiation fixed the issue of stale connections lying around:
client := graphql.NewClient("https://example.com/graphql", graphql.ImmediatelyCloseReqBody())

This is probably way too late to be useful to you, but I was seeing a similar issue. It boiled down to the sender (client) expecting the recipient to close the connection by default which it wasn't doing.
Adding the "ImmediatelyCloseReqBody" flag to the client instantiation fixed the issue of stale connections lying around: client := graphql.NewClient("https://example.com/graphql", graphql.ImmediatelyCloseReqBody())

apparently it is still useful! encountering EOF but couldn't scratch my head on the reason. Will try this out! thank you


The AI cannot follow instructions and does not hold a proper memory

https://bolt.new/~/sb1-cwzzbv
this is my chat
you can see that the AI has been making no progress for the last 15,000 tokens.
It will not follow instructions and continues to repeat previous mistakes, ignoring what we have discussed.
There is a serious flaw in the memory feature and it's not possible to build a great solution when the AI cannot understand the context of the project. I do not have this same issue in Cursor and this is very frustrating as this is more expensive for an inferior product that has wasted my time up to this point.
I provided the AI with an entire solution and wanted it converted in to node.js or whatever it was good at... prompted like 50 times for it to log the code changes and error messages so I could provide them in the chat. I asked it to pay attention and avoid it's repeated mistakes and omissions/oversights as it rewrote code in an attempt to "fix" issues... recreating or creating new issues.
Error:   Failed to scan for dependencies from entries:
/home/project/index.html
/home/project/src/dashboard/index.html
✘ [ERROR] No matching export in "src/dashboard/services/api.js" for import "fetchErrors"
src/dashboard/components/ErrorLog.jsx:3:9:
  3 │ import { fetchErrors } from '../services/api';
    ╵          ~~~~~~~~~~~

at failureErrorWithLog (/home/project/node_modules/esbuild/lib/main.js:1462:15)
at eval (/home/project/node_modules/esbuild/lib/main.js:935:25)
at runOnEndCallbacks (/home/project/node_modules/esbuild/lib/main.js:1305:45)
at buildResponseToResult (/home/project/node_modules/esbuild/lib/main.js:933:7)
at eval (/home/project/node_modules/esbuild/lib/main.js:945:9)
at <anonymous> (https://zp1v56uxy8rdx5ypatb0ockcb9tr6a-oci3-4nj5l1tf.w-credentialless-staticblitz.com/blitz.34c588ed.js:40:21460)
at new Promise (https://zp1v56uxy8rdx5ypatb0ockcb9tr6a-oci3-4nj5l1tf.w-credentialless-staticblitz.com/blitz.34c588ed.js:40:21431)
at requestCallbacks.on-end (/home/project/node_modules/esbuild/lib/main.js:944:54)
at handleRequest (/home/project/node_modules/esbuild/lib/main.js:637:17)

this are mistakes that the AI shouldn't be making... the npm logs are being written to a directory that is hidden and when accessed, it does not include the log file displayed in the terminal... ????
I had a button that was intended to do the following:

Add this functionality - this is the goal, we are not there yet, approach this systematically:
on click, "Test Connection" create a code snapshot AND compare the code snapshot to the previous run, ie: 00000, it will create a file called 00001_current_code.txt for the code snapshot and create an additional file 00001_code_changes_and_log.txt (or .csv or .log, if line numbers will help for debugging, include them) -this will list the changes in the code from the previous version and include the log from the current run.
on click, "Test Connection", a log of what happened on the run needs to be saved to 00001_run_summary that includes the data needed to debug, successful actions and errors, data in JSON format or the terminal message on errors only to provide information for debugging.
Add a button to display 00001_code_changes_and_log to the UI, if possible, also have it copy the data to my clipboard so I can paste it. The button will be called "Display Code Changes and Log", on click display 00001_code_changes and 00001_run_summary in a combined format with proper context labels, this needs to be clear and concise. Save this to a file called 00001_run_analysis as well.
The goal is to be able to provide bolt.new with the most information to be able to proficiently update the code. At the top of the file 00001_run_analysis I want to include a prompt that explains what the data is, what the intention was and what the result was, then a prompt to make calculated and precision updates to the code to debug without omitting any of the previous code or reverting code to previously attempted code changes that we've already proven that did not provide the intended outcome.

It added the button but kept breaking things when trying to fix errors, omitting things and even removed the button entirely with all it's features we'd been working on while trying to bug fix... like serious WTF
I honestly want a refund, almost 20 million tokens and I am no further than I was when I provided my existing code on my first prompt, things have become worse and for some reason the AI cannot understand API REST protocol or if it does, it cannot do it in node.js properly. The JSON it provides has like URL: /sample/test/ when it has been provided with the URL, it removes Authorization: Basic ***** and does not replace ***** with the login:password in base64 as instructed. While trying to bug fix it will revert to the original "sample/test" code without any authorization at all and it's been frustrating, an epic waste of time.

here is another example...
Error
TLS protocol version "TLSv1.2" conflicts with secureProtocol "TLS_method"
API Communication Log
REQUEST
22:51:35.722
{
"method": "POST",
"url": "/filemaker/test"
}
RESPONSE
22:51:49.862
{
"status": 200,
"data": {
"status": "error",
"message": "TLS protocol version "TLSv1.2" conflicts with secureProtocol "TLS_method""
}
}


evaluation with character sequence 'do' in a word

After a lot of head scratching I found the following :
=number_input f, :amount, class: "js-donation-amount"
This blows up with :
== Compilation error on file web/views/investment_view.ex ==
** (EEx.SyntaxError) web/templates/investment/new.html.slim:1: unexpected token ' end '
    (eex) lib/eex/compiler.ex:59: EEx.Compiler.generate_buffer/4
    (phoenix) lib/phoenix/template.ex:320: Phoenix.Template.compile/2
    (phoenix) lib/phoenix/template.ex:154: Phoenix.Template."-MACRO-__before_compile__/2-fun-0-"/3
    (elixir) lib/enum.ex:1261: Enum."-reduce/3-lists^foldl/2-0-"/3
    (phoenix) expanding macro: Phoenix.Template.__before_compile__/1
    web/views/investment_view.ex:1: Sheep.InvestmentView (module)

This happens when I use any character sequence containing "do" in it for the class: attribute
It seems it's not limited to the class attribute though but any for that matter.

Great report @smeevil!  We will look into this

Thanks so much @Rakoth, you're a machine! :+1:

You guys are awesome ! :heart:
First two weeks working with elixir / phoenix so as soon as I have a bit of a better understanding of it , I'll hope I can be of more use !

Thanks @smeevil.  We'd welcome your contribution!


Click is working fine on browser but not mobile emulation

Hi there!

Node Version: v6.11.4

Protractor Version: v5.2.2

Angular Version: v1.4.12

Browser(s): Chrome 63.0.3239.84

ChromeDriver: 2.34

Operating System and Version: Mac High Sierra

Your protractor configuration file

    SpecReporter = require('jasmine-spec-reporter').SpecReporter;

    exports.config =
        seleniumAddress: 'http://localhost:4444/wd/hub'
        specs: ['protractor-spec.js']
        ignoreUncaughtExceptions: true
        allScriptsTimeout: 60000 # 60 seconds timeout
        capabilities: {
            browserName: 'chrome',
            chromeOptions: {
#                'mobileEmulation' : {
#                    'deviceName': 'Nexus 5X'
#                },

                'args': [
                    '--auto-open-devtools-for-tabs'
                ]
            },

        }
        jasmineNodeOpts: print: ->
        onPrepare: ->
            jasmine.getEnv().addReporter(new SpecReporter({
                spec: {
                    displayStacktrace: false
                }
            }));

A relevant example test

describe "Coming Soon tab", ->

        it 'should be able to navigate to Coming Soon tab.', ->
            comingSoonButton = element(By.cssContainingText('.tab__title', 'Coming Soon'))
            comingSoonButton.click()

        it 'should show Coming Soon tab.', ->
            waitForLoading()
            expect(browser.getCurrentUrl()).toContain "/coming-soon"

The test running fine on normal chrome browser, but once I enable mobileEmulation the click() will  cause the browser show right click menu. I suspect it did a right click when mobileEmulation enabled.
Anyone having the same issue that I facing?

Browser(s): Chrome 63.0.3239.108
ChromeDriver: 2.34
I am facing the same issue on chromedriver 2.34 with mobile and tablet emulators.  When webdriver fires a click command, a right click menu is opened on the element instead of a click.  So it seems to be treating click as right click on mobile and tablet emulators. Since I'm using java bindings and 	@nexstreamray is using Protractor, it seems to be related to chromedriver.  Also, I tried running emulator test with chromedriver 2.33 on chrome 63.0.3239.108, it worked fine. So it might have to do something with chromedriver 2.34 not chrome 63.0.3239.108.


Closing tab hangs when using VS Dev tools and Powershell Core

Windows Terminal version
1.16.2524.0
Windows build number
10.0.25201.0
Other Software

Visual Studio 2022
Powershell Core 7.2.6

Steps to reproduce

Create a profile using pwsh.exe in Windows Terminal Preview
Execute the following lines to add the VS dev tools

Import-Module "C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"
Enter-VsDevShell 8ee891c5 -SkipAutomaticLocation -DevCmdArguments "-arch=x64 -host_arch=x64"

Close the tab

Expected Behavior
Tab closes quickly.
Actual Behavior
wt locks up entirely doing...something.

I've tested this with the release version of Windows Terminal and also regular powershell.exe. Both of those don't exhibit the behavior. It is only with Powershell Core, the most recent release of wt.exe and the Visual Studio dev tools

I suspect you are right, I did a few heap dumps to see if I could spot anything of note and I noticed they were both hung on the same line related to the conpty connect, specifically this line https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalConnection/ConptyConnection.cpp#L557

I debugged this just and and it's actually hung somewhere else for me:
(It's hung in WaitForSingleObject(pPty->hConPtyProcess, INFINITE);)

Ah right... The old version used to close the connection in the background only, so it didn't matter how long it took and it wasn't visually apparent either:
https://github.com/microsoft/terminal/commit/666c446bc38f741a7fc17b481ea1c665a4f31d13#diff-baa2e4fc26af1b8722a4eec13221622ef4ae566e4f7a8658bc58806f96b7e9b8L1525-L1526
But as mentioned in the PR, that's not viable at all, because that's a pretty nasty race condition.

@lhecker, I just double checked - I'm hung on the same line. The one I posted earlier was down further in the stack.


vdexExtractor does not extract services.dex in the framework of Android10

Hi @anestisb , I am trying to extract Dexs file from services.vdex. I see in another post you said this can be done through extracting APK file, but services.vdex comes from Android10(API level 29) framework so no APK available. Please see the below. services.vdex is attached. Thanks!
$ vdexExtractor -i services.vdex -v 4
[INFO] Processing 1 file(s) from services.vdex
[DEBUG] [30330] 2020/04/30 13:44:18 (vdexExtractor.c:224 main) Processing 'services.vdex'
[DEBUG] [30330] 2020/04/30 13:44:18 (vdex_api.c:53 vdexApi_initEnv) Initializing environment for Vdex version '021'
------ Vdex Header Info -------
magic header                  : vdex
verifier dependencies version : 021
dex section version           : 000
number of dex files           : 2 (2)
verifier dependencies size    : 1f414 (128020)
verifier dependencies offset  : 24 (36)
quickening info size          : 0 (0)
quickening info offset        : ffffffff<PHONE_NUMBER>)
boot clspath checksums size   : 0 (0)
boot clspath checksums offset : ffffffff<PHONE_NUMBER>)
class loader context size     : 0 (0)
class loader context offset   : ffffffff<PHONE_NUMBER>)
---- EOF Vdex Header Info ----
[DEBUG] [30330] 2020/04/30 13:44:18 (vdex/vdex_backend_021.c:407 vdex_backend_021_process) Vdex has no Dex data - skipping
[DEBUG] [30330] 2020/04/30 13:44:18 (vdex/vdex_021.c:363 vdex_021_process) Took 0 ms to process Vdex file
[INFO] 1 out of 1 Vdex files have been processed
[INFO] 0 Dex files have been extracted in total
[INFO] Extracted Dex files are available in '.'

services.vdex.zip

As far as I know, vdexExtractor can only work when vdex file contains dex file.
And for Android Q version,  dex2oat will not copy dex file to vdex file if dex file is stored with an uncompressed format in the jar file.
So I suggest that you shall first check the origin service.jar file to check whether it  contains the dex files or not.

@jiajunpei Thanks!

@JinghanGuo Did you solve the problem you posted?

aight, so im getting the same errors in android 11, everything seems to work fine, and the services.jar file has exactly 3 too.


Fix kokkos-kernels depends condition

The fix for older spack versions would append kokkos-kernels to specs that did not specify it. Here, a when is added to ensure it is only included when requested in the spec.

I don't fully understand the logic here. Is it just "use the when syntax when appropriate and it's available in the sufficiently new version of spack"?

The logic here was "if spack version is >=17, then depend on kokkos-kernels ~shared", when what it is supposed to be is "if spack version is >=17, AND we depend on kokkos-kernels then depend on kokkos-kernels ~shared"
What was happening for my case was that the default install spec (i.e. not using cuda + kokkos) was bringing in kokkos-kernels anyway

I see... And the versioning of >= 17 means the when syntax is supported?

I see... And the versioning of >= 17 means the when syntax is supported?

when is supported as a keyword arg in depends_on for a while now (since at least it was adopted by LANL). The specific versioning is due to the issue we encountered when trying to install/link with a kokkos-kernels as a shared library with newer spack versions

Got it. Thanks for the explanation.


Need to download "pagedown" manually

Since it's hosted on Google Code, which is now in a frozen archived state, download it from there and extract to "thirdparty" directory, and make sure the directory you just extracted is named "pagedown".
https://code.google.com/archive/p/pagedown/source/default/source
There may be newer forks or releases of pagedown that are maintained, but I don't know which would be supported.

MathB now uses https://github.com/markedjs/marked (a JavaScript library that supports GitHub Flavoured Markdown, a strict superset of the CommonMark specification). The documentation at https://github.com/susam/mathb/blob/main/README.md has been updated with steps to install marked and other dependencies to set up an environment where MathB can run successfully.


Cannot fully clear current input with Ctrl+u or command history

[x] I am on the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: Arch Linux, 5.2.14
Hyper.app version: 3.0.2
Link of a Gist with the contents of your .hyper.js: .hyper.js
Relevant information from devtools (CMD+ALT+I on macOS, CTRL+SHIFT+I elsewhere): N/A
The issue is reproducible in vanilla Hyper.app: Still occurs if I disable all plugins.

Issue
Hi, when I try to clear the current input, a few characters will stick around. Specifically, if the current command I am typing has 15 or more characters entered, clearing or replacing the input (with ctrl+u or cycling through history) will cause the first 10 characters to be left on the line (illustrated in the GIF below).

If I clear any input with 14 characters or less, everything behaves as expected. Any help would be greatly appreciated. Thanks!

Issue unrelated to Hyper. It seems the prompt variable was incorrectly formatted. The prompt PS1='\e[0;34m > \e[m' causes this issue to occur in any terminal emulator.


Do not force "" for http status code

In JSON the key which is a number must be wrapped into "". This is not the case of yaml format. Different formats, different requirements. It does not make sense to force json requirements into yaml and this makes it really annoying to have to use "400": ... in YAML
Please also note that https://editor.swagger.io does not wrap status codes into "", which is correct, but contradictory to this spec:

I propose to remove the requirement of providing status codes as strings in YAML and only keep it for JSON, leaving the alignment for the transformation tool between two formats.
I already created #2147, which got rejected, so now I am opening this issue as the proposal for the next version of the spec.

I think this would not be an improvement to OpenAPI. in terms of general principles, OpenAPI exists to aid interoperability. changes that add ambiguity to how an API can be represented in OpenAPI are counter to that. every tool would now have to look for numeric keys in addition to string keys. it opens up the possibility for collisions if both integer 200 and string "200" are present. it brings in issues of comparing numbers (is 200 equal to 200.0? in some languages all numbers are parsed to floats).
having a single, consistent way to represent an http status obviates all these problems. I appreciate that the aesthetics of having to quote these, when you don't normally have to quote object keys in YAML, is suboptimal. but it is best for keys to remain as strings.
it's unfortunate that the swagger editor uses integer keys. they shouldn't. it looks like these are implicitly converted to strings by their YAML parser (which is not usual and seems plainly incorrect according to the YAML spec - but that's far afield). I will open an issue to correct their examples (unless, of course, the consensus on this issue goes the other way).

In the HTTP/1.1 standard (RFC 7231: https://tools.ietf.org/html/rfc7231#page-47) response status code is described as:

three-digit integer code giving the result of the attempt to understand and satisfy the request.

In all of the languages and libraries I know, they also implemented as an integer.
Forcing in OpenAPI spec to represent response status code as a string is misleading, against HTTP standard and all of the software implementations.
What's worse is that it's done only to cover the limitations of the JSON format not being able to handle numeric kets or to avoid double keys in YAML. I believe such things should be covered by the linting tools, instead OpenAPI spec introducing misleading requirements.

The responses object is defined as a map of string keys to response objects. This is to facilitate the use of range codes like 4XX and the default value.

In all of the languages and libraries I know, it is implemented as an integer.

I've worked with a lot of http libraries, the string/integer decision seems like a coin toss sometimes. arguably an integer is more appropriate, but it doesn't really matter. OpenAPI documents are JSON (even when they are YAML), and in JSON, object keys are strings, not integers.

I am keen to see the library which exposes response status code as string :)
The internals of OpenAPI spec does not matter so much. If the format (like YAML) offering easy transformation to what OpenAPI uses under the hood, this should not force on the format to use something not natural. YAML keys wrapped into "" is not common for this format.
I believe OpenAPI spec should focus on the value it offers (and it's undoubtedly great!) instead of specifying format details.

@MikeRalphson responses could be defined as "integer | string" enum to satisfy the case you have mentioned.

@pkuczynski your proposal would allow situations like this
responses:
  200:
    ...
  "200":
    ...

which would need additional wording in the Spec to ensure the uniqueness of map keys and, as a result, require additional work from tooling vendors.
Using a single data type (string in this case) helps keep things simple.

@hkosova this is a very unlikely situation, where someone would not notice when reviewing the spec (source or rendered to a nice doc) would not notice duplicated keys. And to cover such cases, one can use a linting tool.
I believe that it would be better to say that response code need to be unique, instead of forcing "" on the format, where they are not needed and very not natural to use.

@pkuczynski unlikely based on what? Two people merge a change to an OpenAPI document, both adding 404, one uses string the other doesn't. Now you have a "404" and a 404.

This should be picked up by git as a merge conflict, so the second-person would see it and resolve it. In a rare case of mistake, validation should report it...

That's not actually how git works. 😅

I know how git works, trust me :)

I'm sure.
Anyway, due to the need to support 4XX and the default value, this does need to be a string. Thanks for the interesting discussions.

This entire ticket, and #2147 before it, doesn't make sense. In JSON the only valid format for an object key is a string, so any yaml-to-json translator will turn a numeric key into a stringy key.
For example:
echo "---^M200: a value^M404: another value" | yaml2json
{
  "200" : "a value",
  "404" : "another value"
}

(where yaml2json is a bash function, and I can guarantee that these YAML and JSON backends work properly (the YAML one having been written by the inventor of YAML):
yaml2json ()
{
    perl -MYAML::XS -MJSON::MaybeXS -wle'print JSON()->new->pretty->indent_length(2)->canonical->encode(Load(do { local $/; <> }))' $*
}

@karenetheridge I agree with you. That's why I believe spec should not mention that keys need to be strings, as it is obvious for json and does enforce people to write ugly yaml:
responses:
  "400":
    description: This is a description

instead of totally fine and more yaml-natural way:
responses:
  400:
    description: This is a description

That was the whole point if this issue: don't mention the string format for status code and leave that up to the file format.
Do you know what I mean @karenetheridge?

I am referring to this sentence from https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md

@pkuczynski I see what you mean. I agree, I think, but I will sit this one out as I am 1. not heavily involved in OpenAPI, and 2. work in a language that only has stringy keys so the YAML loading would work fine for me in any case (I apologize for my privilege blinding me to the oppression that others are dealing with) 😁

At least one person understands what I am talking, thank you @karenetheridge :)
This issue is closed so I guess its a lost case anyway...

@pkuczynski @karenetheridge what @philsturgeon is this:
detective-eye:~ handrews$ cat foo.yaml
---
400: foo
"400": bar

detective-eye:~ handrews$ python
Python 2.7.16 (default, Jan 27 2020, 04:46:15)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import yaml
>>> yaml.load(open('foo.yaml'))
{400: 'foo', '400': 'bar'}
>>>

Given a long list of errors, where there's already a 400 buried in there somewhere, someone could easily add a "400", which would absolutely not be a git conflict.  Now you've got two different status 400 responses which some languages, such as Python, can parse preserving both entries, but others, such as JavaScript with the popular js-yaml package, cannot:
detective-eye:json-schema-tools handrews$ node
> yaml = require('js-yaml');
> fs   = require('fs');
> yaml.safeLoad(fs.readFileSync('/Users/handrews/foo.yaml', 'utf8'));
{ YAMLException: duplicated mapping key at line 3, column 1:
    "400": bar
    ^
    at generateError (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:165:10)
    at throwError (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:171:9)
    at storeMappingPair (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:308:7)
    at readBlockMapping (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:1071:9)
    at composeNode (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:1332:12)
    at readDocument (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:1492:3)
    at loadDocuments (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:1548:5)
    at load (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:1569:19)
    at Object.safeLoad (/Users/handrews/src/json-schema-tools/node_modules/js-yaml/lib/js-yaml/loader.js:1591:10)
  name: 'YAMLException',
  reason: 'duplicated mapping key',
  mark:
   Mark {
     name: null,
     buffer: '---\n400: foo\n"400": bar\n\n\u0000',
     position: 13,
     line: 2,
     column: 0 },
  message:
   'duplicated mapping key at line 3, column 1:\n    "400": bar\n    ^' }
>

Saving two keystrokes to quote your keys is not worth this headache.

I know what @philsturgeon is trying to say, buts I simply don't think OpenAPI should be worried about details of formatting. It should be left alone to the specific format itself. It.would be enough to say, that error codes should be unique and the linting tool should be the one holding the guard.
Currently, some yaml linters happily accept duplicated keys no matter if they in or without quotes. I used following example:
---
responses:
  404: abc
  404: cde
  "404": abcd

And following lint parsers considered this code totally valid (despite using quotes):

http://www.yamllint.com
https://codebeautify.org/yaml-validator
https://jsonformatter.org/yaml-validator
http://beautifytools.com/yaml-validator.php
https://yaml-online-parser.appspot.com

They clearly don't follow the spec https://yaml.org/spec/1.2/spec.html#id2759572, but it would only mean that your enforcement of putting things into quotes does not serve the purpose. It should rather formulate that keys should be uniq. Thats also what YAML 1.2 spec says, but not JSON spec (JSON's RFC4627 requires that mappings keys merely “SHOULD” be unique)
Following some other YAML parsers online, implementing YAML 1.2 spec you will notice that they would report duplicated keys in this example:
---
responses:
  404: abc
  "404": cde

https://yamlchecker.com
https://onlineyamltools.com/validate-yaml

So if python yaml parser does not do that, you should report an error there, instead of forcing people to write in yaml response statuses wrapped in quotes

I appreciate the mentions but I have to keep coming back here to unsubscribe.

@pkuczynski Pointing out the wobbly inconsistency of YAML tooling is really not making your case any stronger.  I think I'll unsubscribe from this, too, as I find the whole complaint utterly baffling.
I'm of the "there should be one way to do things" mentality when it comes to specs like this, and there's clearly only one option that works for every format and every use of that field (which is not limited to numbers).  Everything else is needlessly complicated.


Morphia Aggregation Pipeline always returns the same data

Hi! I've put a question at StackOverflow, but I think it might be an issue. To avoid copy/pasting it, here is the link:
http://stackoverflow.com/questions/37123794/morphia-aggregation-pipeline-always-returns-the-same-data
Debugging, I found out that my problem was the cache used internally in MorphiaIterator. Although every iteration should return different items, since the ID of the main item is the same, it returns always the same item from the internal cache.
The point is in fromDb method in Mapper class. It uses the cache from the iterator. Debugging in the processItem method shows that in:
final V item = convertItem(dbObj);
The final item is different from the dbObj, (dbObj content is right).
I think that it should be possible to either clear the cache in between iterations of the loop (worst solution in my oppinion), or to be able to tell the Pipeline not to use the cache to build the items.
Best regards

You're running in to this issue: #854.   You'll need to suppress the _id fields.

But I also need the "_id" field in my case...

I'm afraid the two requirements are contradictory.   You might try projecting the _id field to id so that subsequent documents aren't conflated unnecessarily.  But by unwinding you're creating multiple docs with duplicate IDs which doesn't work for a number of reasons.


[BUG] Able to create multiple organizations with the same name

Attachment: https://drive.google.com/drive/folders/1WBCGwFCULq11K0Tj5RsaoqqFvMtz3zQg?usp=sharing
Browser Details: Chrome
Device Details: macOS 10.15.6 (MacBook Pro)
Note: Tried on the cloud.
Issue: Able to create multiple organizations with the same name.

@Saket2 I believe org names are not unique in appsmith. @mohanarpit please confirm


Bump flake8 WPS plugin to v0.16.0

The 0.16.x stream is the first one compatible with flake8 v4.

Yep, that's still the case.


Directional movement between outputs, floats

My setup is:
External monitor with pos: 0,0
Laptop monitor with pos: 3840,0
My external monitor is physically positioned to the left of my laptop.
The original focus command in sway allows me to

Have focus in a window/container on my laptop-screen
Press mod+Left
Get focus on a window on my external monitor (positioned to the left of my laptop both virtually and physically)

sway_bfocus does not transcend desktop boundaries.
If the aim is to replace the focus command, all "active desktops", i.e. those that are currently displayed, should be taken into account when switching focus.

Both floats and outputs need directional movement that is based on the positions and dimensions of containers. This isn't possible to do with plain tree traversal.
The API might also need to be revamped again. I have a suspicion that there are a lot of possible edge case configurations that should be considered.

Features have been implemented.


invisible delimiter in macro expansion

As discussion in PR #1125 , we want to add 2 two new token kinds (L_DOLLAR and R_DOLLAR) for fixing the parser such that it doesn't break Delimiter::None subtrees.
Background
However, i just find out the current parser did not break by Delimiter::None in simple way. For example:
rules
        macro_rules! foo {
            ($ i:expr) => {
                 fn bar() { $ i * 10; }
            }
        }

invocation
"foo! { 2 + 2 }",

It will expand to fn bar () {2 + 2 * 10 ;} , which seem to be wrong, because we would like to get back fn bar() {(2+2) * 10; } for preserving the execution order.
In the ast tree point of view, the macro expansion of (2+2) * 10 would look like this:
BIN_EXPR
    LITERAL
        INT_NUMBER
    PLUS
    BIN_EXPR
        LITERAL
            INT_NUMBER
        STAR
        LITERAL
            INT_NUMBER

The suggested solution in the previous discussion is adding two token kinds: L_DOLLAR and R_DOLLOR for invisible delimiter in macro expansion to fix this problem.
Proposal
But after i do some research about how rustc mbe works, i will proposal add a new MARCO_INTERPOLATED node after macro expansion. so the ast tree would became:
BIN_EXPR
    MARCO_INTERPOLATED
        LITERAL
            INT_NUMBER
        PLUS
        LITERAL
            INT_NUMBER
    STAR
    LITERAL
        INT_NUMBER

The reasons are:

It simplify the parser logic: We don't need to add new token kinds.
Even we add the new token kinds, we still need to add a new node for contain it:

BIN_EXPR
    DOLLOR_EXPR    <- Dolar expression ??
        LITERAL
            INT_NUMBER
        PLUS
        LITERAL
            INT_NUMBER
    STAR
    LITERAL
        INT_NUMBER

Right now Delimiter::None only happens in the top level of macro expansion and it should not be seen in later stage of parsing.

However, i am not sure how it affect hir code and other parts of ra.

An excellent observation! My understanding is that interpolated tokens in rustc are specific for macro-by-example, and are not available for proc-macros. In rust-analyzer, I would love to handle proc-macros and mbe macros using the exact same API of token trees (this is why tt crate exists separately from the rest of the compiler), and proc_macro's tt do not have interpolated nodes.
If we don't touch ra_tt, we still can add interpolated nodes to mbe specifically, by mirroring ra_tt trees inside mbe (which we do anyway for $captures).
However, I think we must handle Nones in parer correctly anyway, because proc-macros would use that. in other words, I think that if foo is written as a proc_macro, it still gets the correct expansion in rustc, without using interpolated tokens (i might be wrong here).
So, I think the way forward here is

verify the theory that we should handle None anyway for proc macros
implement mbe using None
(future) improve mbe by using interpolated: this should be more efficient, b/c we will be able to share green trees. Moreover, I think correct handlng of mbe requires interpolated, because mbe forbid to capture and $e:expr and then reparsing it as $ty:ty, but the Delimiter::None approach allows it.

i will proposal add a new MARCO_INTERPOLATED node after macro expansion. so the ast tree would became:

I don't think we need MACRO_INTERPOLATED in the final tree, it should look like
BIN_EXPR
    BIN_EXPR
        LITERAL
            INT_NUMBER
        PLUS
        LITERAL
            INT_NUMBER
    STAR
    LITERAL
        INT_NUMBER

That is, if you print this tree, you get a "wrong" result, but we care about the tree structure, and it could be correct even without introducing an additional node

@edwin0cheng if you are around, we have an MBE meeting in the Zulip right now ;)

@matklad Just want to clarify, if i expand following marco :
macro_rules! structs {
    ($($i:ident),*) => {
        $(struct $i { field: u32 } )*
    }
}

Is it the syntax tree output with L_DOLLAR and R_DOLLAR you expected ?
SOURCE_FILE@[0; 40)
  L_DOLLAR@[0; 0) ""
  L_DOLLAR@[0; 0) ""
  L_DOLLAR@[0; 0) ""
  STRUCT_DEF@[0; 20)
    STRUCT_KW@[0; 6) "struct"
    NAME@[6; 9)
      IDENT@[6; 9) "Foo"
    NAMED_FIELD_DEF_LIST@[9; 20)
      L_CURLY@[9; 10) "{"
      NAMED_FIELD_DEF@[10; 19)
        NAME@[10; 15)
          IDENT@[10; 15) "field"
        COLON@[15; 16) ":"
        PATH_TYPE@[16; 19)
          PATH@[16; 19)
            PATH_SEGMENT@[16; 19)
              NAME_REF@[16; 19)
                IDENT@[16; 19) "u32"
      R_CURLY@[19; 20) "}"
  R_DOLLAR@[20; 20) ""
  L_DOLLAR@[20; 20) ""
  STRUCT_DEF@[20; 40)
    STRUCT_KW@[20; 26) "struct"
    NAME@[26; 29)
      IDENT@[26; 29) "Bar"
    NAMED_FIELD_DEF_LIST@[29; 40)
      L_CURLY@[29; 30) "{"
      NAMED_FIELD_DEF@[30; 39)
        NAME@[30; 35)
          IDENT@[30; 35) "field"
        COLON@[35; 36) ":"
        PATH_TYPE@[36; 39)
          PATH@[36; 39)
            PATH_SEGMENT@[36; 39)
              NAME_REF@[36; 39)
                IDENT@[36; 39) "u32"
      R_CURLY@[39; 40) "}"
  R_DOLLAR@[40; 40) ""
  R_DOLLAR@[40; 40) ""
  R_DOLLAR@[40; 40) ""

PS: The first Delimiter::None is added in parsing the whole macro (rhs), the second one is parsing the $repeat, the third one is expanding the $repeat

@edwin0cheng no, I would expect that there wouldn't be any explicit dollars in the final tree. Basically, when the tree-building TreeSink sees a dollar token, it should just discard it. The nesting structure of the tree should be correct nonetheless.
In other words, dollars are for parser, but not for the final tree

Ah.....But current parser cannot discard a token...

Yeah, it's the tree sink who will discard the token, not the parser

SPecifically, here shold be an if kind != L_DOLLAR: https://github.com/rust-analyzer/rust-analyzer/blob/e6e2571bdf780d304c792d4317bbaf1d6f5d7a0a/crates/ra_mbe/src/syntax_bridge.rs#L137

It fixed in #1138


[Bug] Destroy citrix_zone not working  ⚠

Thanks for taking the time to fill out this bug report! Before submitting this issue please check the open bugs to ensure the bug has not already been reported. If it has been reported give it a 👍
If this bug is present when using the Citrix service UI or REST APIs then it is not a bug in the provider but rather a bug in the underlying service or the environment. In some cases there can be an enhancement in the provider to handle the error better. Please open a feature request instead of a bug in this case. For more information see CONTRIBUTING.md#provider-issue-vs-product-issue-vs-configuration-issue.
Describe the bug
Summary of the issue
I can successfully ✅  create a citrix_cloud_resource_location and ✅citrix_zone via 🚀Terraform. However, when I attempt to delete them, although they are removed from the Terraform state, they still appear in the Citrix DaaS GUI and PowerShell.
Upon running terraform 💥 destroy, I receive the following warning in the shell:
Warning: Attempting to delete Zone
│
│   with citrix_zone.example-zone,
│   on main.tf line 139, in resource "citrix_zone" "example-zone":
│  139: resource "citrix_zone" "example-zone" {
│
│ Zones and Cloud Connectors are managed only by Citrix Cloud. The requested zone will be deleted from terraform state but you will still need to manually delete these resources by logging into Citrix Cloud.

Even after the resources are removed via Terraform, they still appear in the DaaS  & PowerShell.
As part of the CI/CD 🔄 process, we frequently redeploy and destroy the entire Terraform setup.
My question ❓ is:
How can I permanently delete these old zones?
Get-ConfigZone -Name mvd-025-P-azure

ControllerNames                           : {}
ControllerSids                            : {}
Description                               :
EnableHybridConnectivityForResourceLeases : False
EnableVdaConnectivityForResourceLeases    : False
ExternalUid                               : 4cee8979-988c-44da-b08a-23a07c15c04b
HasValidEdgeServers                       : False
IsHealthy                                 : True
IsPrimary                                 : False
LastStateChangeTimeInUtc                  : 30.09.2024 19:08:43
MetadataMap                               : {[ManagedBy, Terraform]}
Name                                      : mvd-025-P-azure
TenantId                                  :
Uid                                       : 34cbee14-2910-41f4-afcc-ec329fbda74b

Terraform command (import, apply, etc):
Resource impacted:
resource "citrix_cloud_resource_location" "example-resource-location" {
  name = "mvd-025-P-azure"
}

resource "citrix_zone" "example-zone" {
  resource_location_id = citrix_cloud_resource_location.example-resource-location.id
}

Versions
Use the terraform -v command to find the Terraform and Citrix Provider versions.
Terraform: Terraform v1.7.2
citrix/citrix provider: 1.0.4
Operation system:  WSL
Terraform console output
Paste the output from Terraform CLI including any errors and the transactionIds if present.
Warning: Attempting to delete Zone
│
│   with citrix_zone.example-zone,
│   on main.tf line 139, in resource "citrix_zone" "example-zone":
│  139: resource "citrix_zone" "example-zone" {
│
│ Zones and Cloud Connectors are managed only by Citrix Cloud. The requested zone will be deleted from terraform state but you will still need to manually delete these resources by logging into Citrix Cloud.
If the output references a file in the temp directory include it as well.
Terraform log file
If the issue is reproducible enable Terraform debug logging using one of the commands below. Then reproduce the issue and include the resulting log file. More information about Terraform logging is available [here]
(https://developer.hashicorp.com/terraform/plugin/log/managing#enable-logging).
2024-09-30T19:01:29.688+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Received request: tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/tf5server/server.go:743 @module=sdk.proto tf_proto_version=5.6 tf_resource_type=random_pet timestamp=2024-09-30T19:01:29.688+0200
2024-09-30T19:01:29.688+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Sending request downstream: @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/internal/tf5serverlogging/downstream_request.go:22 @module=sdk.proto tf_proto_version=5.6 tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 tf_resource_type=random_pet tf_rpc=UpgradeResourceState timestamp=2024-09-30T19:01:29.688+0200
2024-09-30T19:01:29.688+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Checking ResourceTypes lock: tf_provider_addr=registry.terraform.io/hashicorp/random tf_rpc=UpgradeResourceState @module=sdk.framework tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 tf_resource_type=random_pet @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server.go:420 timestamp=2024-09-30T19:01:29.688+0200
2024-09-30T19:01:29.688+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Checking ResourceTypes lock: @module=sdk.framework tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 tf_resource_type=random_pet tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server.go:420 timestamp=2024-09-30T19:01:29.688+0200
2024-09-30T19:01:29.688+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Calling provider defined Resource Schema method: tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 tf_resource_type=random_pet tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server.go:512 @module=sdk.framework timestamp=2024-09-30T19:01:29.688+0200
2024-09-30T19:01:29.689+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Called provider defined Resource Schema method: tf_provider_addr=registry.terraform.io/hashicorp/random tf_resource_type=random_pet tf_rpc=UpgradeResourceState @module=sdk.framework @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server.go:514 tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 timestamp=2024-09-30T19:01:29.688+0200
2024-09-30T19:01:29.689+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: UpgradeResourceState request version matches current Schema version, using framework defined passthrough implementation: @module=sdk.framework tf_provider_addr=registry.terraform.io/hashicorp/random tf_resource_type=random_pet @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server_upgraderesourcestate.go:87 tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 tf_rpc=UpgradeResourceState timestamp=2024-09-30T19:01:29.688+0200
2024-09-30T19:01:29.689+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Received downstream response: @module=sdk.proto diagnostic_warning_count=0 tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/internal/tf5serverlogging/downstream_request.go:42 diagnostic_error_count=0 tf_proto_version=5.6 tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_duration_ms=0 tf_resource_type=random_pet timestamp=2024-09-30T19:01:29.689+0200
2024-09-30T19:01:29.689+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Served request: @module=sdk.proto tf_proto_version=5.6 tf_resource_type=random_pet tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/tf5server/server.go:762 tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=dfdf5720-286f-94af-a457-58671a3d5509 timestamp=2024-09-30T19:01:29.689+0200
random_pet.main: Destroying... [id=current-crappie]
2024-09-30T19:01:29.689+0200 [INFO]  Starting apply for random_pet.main
2024-09-30T19:01:29.689+0200 [DEBUG] random_pet.main: applying the planned Delete change
2024-09-30T19:01:29.689+0200 [TRACE] GRPCProvider: ApplyResourceChange
2024-09-30T19:01:29.690+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Received request: tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 tf_resource_type=random_pet tf_proto_version=5.6 tf_provider_addr=registry.terraform.io/hashicorp/random @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/tf5server/server.go:852 @module=sdk.proto tf_rpc=ApplyResourceChange timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.690+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Sending request downstream: tf_resource_type=random_pet tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/internal/tf5serverlogging/downstream_request.go:22 tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 @module=sdk.proto tf_proto_version=5.6 timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.690+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Checking ResourceTypes lock: @module=sdk.framework tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 tf_resource_type=random_pet @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server.go:420 tf_rpc=ApplyResourceChange timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.690+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: ApplyResourceChange received no PlannedState, running DeleteResource: tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 tf_resource_type=random_pet tf_rpc=ApplyResourceChange @module=sdk.framework tf_provider_addr=registry.terraform.io/hashicorp/random @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server_applyresourcechange.go:68 timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.690+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Calling provider defined Resource Delete: @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server_deleteresource.go:99 @module=sdk.framework tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 tf_resource_type=random_pet tf_rpc=ApplyResourceChange timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.691+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Called provider defined Resource Delete: @module=sdk.framework tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server_deleteresource.go:101 tf_resource_type=random_pet tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.691+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: No provider defined Delete errors detected, ensuring State and Private are cleared: tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-framework@v1.8.0/internal/fwserver/server_deleteresource.go:104 tf_provider_addr=registry.terraform.io/hashicorp/random tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 tf_resource_type=random_pet @module=sdk.framework timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.691+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Received downstream response: tf_provider_addr=registry.terraform.io/hashicorp/random tf_resource_type=random_pet @module=sdk.proto diagnostic_warning_count=0 tf_proto_version=5.6 tf_req_duration_ms=0 tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/internal/tf5serverlogging/downstream_request.go:42 diagnostic_error_count=0 timestamp=2024-09-30T19:01:29.690+0200
2024-09-30T19:01:29.691+0200 [TRACE] provider.terraform-provider-random_v3.6.2_x5: Served request: tf_proto_version=5.6 tf_provider_addr=registry.terraform.io/hashicorp/random tf_resource_type=random_pet @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/tf5server/server.go:878 tf_req_id=27d6461d-5442-5fab-1423-bd1b9e3e32b1 tf_rpc=ApplyResourceChange @module=sdk.proto timestamp=2024-09-30T19:01:29.691+0200
2024-09-30T19:01:29.691+0200 [TRACE] NodeAbstractResouceInstance.writeResourceInstanceState to workingState for random_pet.main
2024-09-30T19:01:29.691+0200 [TRACE] NodeAbstractResouceInstance.writeResourceInstanceState: removing state object for random_pet.main
random_pet.main: Destruction complete after 0s
2024-09-30T19:01:29.691+0200 [DEBUG] State storage remote.State declined to persist a state snapshot
2024-09-30T19:01:29.691+0200 [TRACE] vertex "random_pet.main (destroy)": visit complete
2024-09-30T19:01:29.691+0200 [TRACE] vertex "provider["registry.terraform.io/hashicorp/random"] (close)": starting visit (terraform.graphNodeCloseProvider)
2024-09-30T19:01:29.692+0200 [TRACE] GRPCProvider: Close
2024-09-30T19:01:29.693+0200 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = error reading from server: EOF"
2024-09-30T19:01:29.695+0200 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/random/3.6.2/linux_amd64/terraform-provider-random_v3.6.2_x5 pid=10117
2024-09-30T19:01:29.695+0200 [DEBUG] provider: plugin exited
2024-09-30T19:01:29.695+0200 [TRACE] vertex "provider["registry.terraform.io/hashicorp/random"] (close)": visit complete
2024-09-30T19:01:30.238+0200 [INFO]  provider.terraform-provider-citrix_v1.0.4: Orchestration API request: tf_rpc=ConfigureProvider transactionId=f1769320-20c2-4fbc-9278-54183d31db1c citrix_customer_id=* citrix_on_premises=false tf_req_id=800d6397-2f94-a300-548d-136e22b3b092 @caller=github.com/citrix/terraform-provider-citrix/internal/middleware/middleware.go:60 tf_provider_addr=registry.terraform.io/citrix/citrix @module=citrix citrix_hostname=api.cloud.com url=https://api.cloud.com/cvad/manage/me citrix_client_secret=*** method=GET citrix_client_id=c6ee4d7c-c1e8-472e-95bc-92d51f8144df timestamp=2024-09-30T19:01:30.237+0200
2024-09-30T19:01:30.461+0200 [INFO]  provider.terraform-provider-citrix_v1.0.4: Orchestration API request: citrix_on_premises=false method=GET tf_req_id=800d6397-2f94-a300-548d-136e22b3b092 tf_rpc=ConfigureProvider citrix_client_secret=*** @caller=github.com/citrix/terraform-provider-citrix/internal/middleware/middleware.go:60 citrix_customer_id=*** citrix_hostname=api.cloud.com tf_provider_addr=registry.terraform.io/citrix/citrix transactionId=e182ad8c-9d52-413a-9613-2b3e16726443 @module=citrix citrix_client_id=c6ee4d7c-c1e8-472e-95bc-92d51f8144df url=https://api.cloud.com/cvad/manage/Sites/a259e2f4-ff00-4648-b753-f7e536c731b7 timestamp=2024-09-30T19:01:30.461+0200
2024-09-30T19:01:30.528+0200 [INFO]  provider.terraform-provider-citrix_v1.0.4: Configured Citrix API client: success=true tf_provider_addr=registry.terraform.io/citrix/citrix @caller=github.com/citrix/terraform-provider-citrix/internal/provider/provider.go:410 @module=citrix tf_req_id=800d6397-2f94-a300-548d-136e22b3b092 tf_rpc=ConfigureProvider timestamp=2024-09-30T19:01:30.528+0200
2024-09-30T19:01:30.528+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Called provider defined Provider Configure: tf_req_id=800d6397-2f94-a300-548d-136e22b3b092 tf_rpc=ConfigureProvider @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_configureprovider.go:23 @module=sdk.framework tf_provider_addr=registry.terraform.io/citrix/citrix timestamp=2024-09-30T19:01:30.528+0200
2024-09-30T19:01:30.528+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received downstream response: diagnostic_warning_count=0 tf_req_duration_ms=847 @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:42 diagnostic_error_count=0 tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=800d6397-2f94-a300-548d-136e22b3b092 tf_rpc=ConfigureProvider @module=sdk.proto timestamp=2024-09-30T19:01:30.528+0200
2024-09-30T19:01:30.528+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Served request: @module=sdk.proto tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=800d6397-2f94-a300-548d-136e22b3b092 tf_rpc=ConfigureProvider tf_proto_version=6.6 @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:570 timestamp=2024-09-30T19:01:30.528+0200
2024-09-30T19:01:30.528+0200 [TRACE] vertex "provider["registry.terraform.io/citrix/citrix"]": visit complete
2024-09-30T19:01:30.528+0200 [TRACE] vertex "citrix_zone.example-zone (destroy)": starting visit (*terraform.NodeDestroyResourceInstance)
2024-09-30T19:01:30.528+0200 [TRACE] readDiff: Read Delete change from plan for citrix_zone.example-zone
2024-09-30T19:01:30.528+0200 [TRACE] readResourceInstanceState: reading state for citrix_zone.example-zone
2024-09-30T19:01:30.528+0200 [TRACE] upgradeResourceState: schema version of citrix_zone.example-zone is still 0; calling provider "citrix" for any other minor fixups
2024-09-30T19:01:30.528+0200 [TRACE] GRPCProvider.v6: UpgradeResourceState
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received request: @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:744 @module=sdk.proto tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 tf_resource_type=citrix_zone tf_rpc=UpgradeResourceState timestamp=2024-09-30T19:01:30.528+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Sending request downstream: tf_resource_type=citrix_zone tf_rpc=UpgradeResourceState tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:22 @module=sdk.proto tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix timestamp=2024-09-30T19:01:30.529+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Checking ResourceTypes lock: tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:510 @module=sdk.framework tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_zone timestamp=2024-09-30T19:01:30.529+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Checking ResourceTypes lock: tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:510 tf_resource_type=citrix_zone @module=sdk.framework tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 timestamp=2024-09-30T19:01:30.529+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Calling provider defined Resource Schema method: @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:602 tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 tf_resource_type=citrix_zone @module=sdk.framework tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=UpgradeResourceState timestamp=2024-09-30T19:01:30.529+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Called provider defined Resource Schema method: tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:604 @module=sdk.framework tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_zone timestamp=2024-09-30T19:01:30.529+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: UpgradeResourceState request version matches current Schema version, using framework defined passthrough implementation: @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_upgraderesourcestate.go:87 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 tf_resource_type=citrix_zone tf_rpc=UpgradeResourceState @module=sdk.framework timestamp=2024-09-30T19:01:30.529+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received downstream response: diagnostic_warning_count=0 tf_proto_version=6.6 tf_req_duration_ms=0 tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 tf_resource_type=citrix_zone @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:42 @module=sdk.proto diagnostic_error_count=0 tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=UpgradeResourceState timestamp=2024-09-30T19:01:30.529+0200
2024-09-30T19:01:30.529+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Served request: tf_rpc=UpgradeResourceState tf_resource_type=citrix_zone tf_req_id=ab768673-dd53-f0b0-3040-49004fe0ee37 @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:763 @module=sdk.proto tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix timestamp=2024-09-30T19:01:30.529+0200
citrix_zone.example-zone: Destroying... [id=34cbee14-2910-41f4-afcc-ec329fbda74b]
2024-09-30T19:01:30.529+0200 [INFO]  Starting apply for citrix_zone.example-zone
2024-09-30T19:01:30.529+0200 [DEBUG] citrix_zone.example-zone: applying the planned Delete change
2024-09-30T19:01:30.529+0200 [TRACE] GRPCProvider.v6: ApplyResourceChange
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received request: tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_zone tf_rpc=ApplyResourceChange @module=sdk.proto tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:852 tf_proto_version=6.6 timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Sending request downstream: tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:22 @module=sdk.proto tf_resource_type=citrix_zone tf_rpc=ApplyResourceChange timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Checking ResourceTypes lock: tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:510 tf_resource_type=citrix_zone @module=sdk.framework timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: ApplyResourceChange received no PlannedState, running DeleteResource: @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_applyresourcechange.go:68 tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=ApplyResourceChange @module=sdk.framework tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b tf_resource_type=citrix_zone timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Resource implements ResourceWithConfigure: tf_rpc=ApplyResourceChange tf_provider_addr=registry.terraform.io/citrix/citrix @module=sdk.framework tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b tf_resource_type=citrix_zone @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_deleteresource.go:45 timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Calling provider defined Resource Configure: tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b tf_resource_type=citrix_zone @module=sdk.framework @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_deleteresource.go:52 tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=ApplyResourceChange timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Called provider defined Resource Configure: tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_deleteresource.go:54 @module=sdk.framework tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_zone timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Calling provider defined Resource Delete: tf_resource_type=citrix_zone tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_deleteresource.go:99 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b @module=sdk.framework timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Called provider defined Resource Delete: @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_deleteresource.go:101 tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_zone tf_rpc=ApplyResourceChange @module=sdk.framework tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: No provider defined Delete errors detected, ensuring State and Private are cleared: tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_deleteresource.go:104 tf_resource_type=citrix_zone tf_rpc=ApplyResourceChange @module=sdk.framework timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received downstream response: @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:42 diagnostic_warning_count=0 tf_req_duration_ms=0 tf_rpc=ApplyResourceChange @module=sdk.proto diagnostic_error_count=0 tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b tf_resource_type=citrix_zone timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Served request: @module=sdk.proto tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=add1fe6b-d1bf-f857-14ea-afa4f2fc824b tf_resource_type=citrix_zone tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:878 timestamp=2024-09-30T19:01:30.530+0200
2024-09-30T19:01:30.530+0200 [TRACE] NodeAbstractResouceInstance.writeResourceInstanceState to workingState for citrix_zone.example-zone
2024-09-30T19:01:30.531+0200 [TRACE] NodeAbstractResouceInstance.writeResourceInstanceState: removing state object for citrix_zone.example-zone
citrix_zone.example-zone: Destruction complete after 0s
2024-09-30T19:01:30.531+0200 [DEBUG] State storage *remote.State declined to persist a state snapshot
2024-09-30T19:01:30.531+0200 [TRACE] vertex "citrix_zone.example-zone (destroy)": visit complete
2024-09-30T19:01:30.531+0200 [TRACE] vertex "citrix_cloud_resource_location.example-resource-location (destroy)": starting visit (*terraform.NodeDestroyResourceInstance)
2024-09-30T19:01:30.531+0200 [TRACE] readDiff: Read Delete change from plan for citrix_cloud_resource_location.example-resource-location
2024-09-30T19:01:30.531+0200 [TRACE] readResourceInstanceState: reading state for citrix_cloud_resource_location.example-resource-location
2024-09-30T19:01:30.531+0200 [TRACE] upgradeResourceState: schema version of citrix_cloud_resource_location.example-resource-location is still 0; calling provider "citrix" for any other minor fixups
2024-09-30T19:01:30.531+0200 [TRACE] GRPCProvider.v6: UpgradeResourceState
2024-09-30T19:01:30.531+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received request: tf_resource_type=citrix_cloud_resource_location @module=sdk.proto tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:744 timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.531+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Sending request downstream: @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:22 @module=sdk.proto tf_rpc=UpgradeResourceState tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 tf_resource_type=citrix_cloud_resource_location timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.531+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Checking ResourceTypes lock: tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:510 @module=sdk.framework tf_resource_type=citrix_cloud_resource_location tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.531+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Checking ResourceTypes lock: @module=sdk.framework tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 tf_resource_type=citrix_cloud_resource_location tf_rpc=UpgradeResourceState tf_provider_addr=registry.terraform.io/citrix/citrix @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:510 timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.531+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Calling provider defined Resource Schema method: @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:602 @module=sdk.framework tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 tf_resource_type=citrix_cloud_resource_location tf_rpc=UpgradeResourceState timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Called provider defined Resource Schema method: tf_resource_type=citrix_cloud_resource_location tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:604 @module=sdk.framework timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: UpgradeResourceState request version matches current Schema version, using framework defined passthrough implementation: tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 @module=sdk.framework tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_cloud_resource_location tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server_upgraderesourcestate.go:87 timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received downstream response: @module=sdk.proto diagnostic_error_count=0 tf_req_duration_ms=0 tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 tf_resource_type=citrix_cloud_resource_location tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:42 diagnostic_warning_count=0 timestamp=2024-09-30T19:01:30.531+0200
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Served request: @module=sdk.proto tf_req_id=40dcc230-5c38-1c4f-c147-14d77f64f977 tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_cloud_resource_location tf_rpc=UpgradeResourceState @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:763 tf_proto_version=6.6 timestamp=2024-09-30T19:01:30.532+0200
citrix_cloud_resource_location.example-resource-location: Destroying... [id=4cee8979-988c-44da-b08a-23a07c15c04b]
2024-09-30T19:01:30.532+0200 [INFO]  Starting apply for citrix_cloud_resource_location.example-resource-location
2024-09-30T19:01:30.532+0200 [DEBUG] citrix_cloud_resource_location.example-resource-location: applying the planned Delete change
2024-09-30T19:01:30.532+0200 [TRACE] GRPCProvider.v6: ApplyResourceChange
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Received request: tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=ApplyResourceChange tf_proto_version=6.6 tf_req_id=842d2753-6a82-4b8a-e7dd-ed51934d9e04 tf_resource_type=citrix_cloud_resource_location @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/tf6server/server.go:852 @module=sdk.proto timestamp=2024-09-30T19:01:30.532+0200
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Sending request downstream: @module=sdk.proto tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/citrix/citrix tf_resource_type=citrix_cloud_resource_location tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/terraform-plugin-go@v0.24.0/tfprotov6/internal/tf6serverlogging/downstream_request.go:22 tf_req_id=842d2753-6a82-4b8a-e7dd-ed51934d9e04 timestamp=2024-09-30T19:01:30.532+0200
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: Checking ResourceTypes lock: @caller=github.com/hashicorp/terraform-plugin-framework@v1.12.0/internal/fwserver/server.go:510 tf_provider_addr=registry.terraform.io/citrix/citrix tf_rpc=ApplyResourceChange @module=sdk.framework tf_req_id=842d2753-6a82-4b8a-e7dd-ed51934d9e04 tf_resource_type=citrix_cloud_resource_location timestamp=2024-09-30T19:01:30.532+0200
2024-09-30T19:01:30.532+0200 [TRACE] provider.terraform-provider-citrix_v1.0.4: ApplyResourceChange received no PlannedState, running DeleteResource: tf_provider_addr=registry.terraform.io/citrix/citrix tf_req_id=842d2753-6a82-4b8a-
cmd:
set TF_LOG="DEBUG"
set TF_LOG_PATH="./citrix-provider-issue.txt"
terraform <command>

Powershell:
$env:TF_LOG="DEBUG"
$env:TF_LOG_PATH="./citrix-provider-issue.txt"
terraform <command>

bash:
export TF_LOG="DEBUG"
export TF_LOG_PATH="./citrix-provider-issue.txt"
terraform <command>

Hi @dimi4ik ,
For a Citrix Cloud customer, DaaS zone comes from a resource location. There is a delay between Citrix Cloud Resource Location Create / Delete, and the zone availability in DaaS.
In your case, once a Resource Location is deleted, the zone will take a few minutes to "sync" the deletion status. We will remove zone from state immediately during terraform destroy so that it is no longer a blocker for Resource Location deletion. But the zone might still be in your site waiting to "sync" the deletion of the Resource Location.
A simple solution is to wait a few minutes in between Resource Location and Zone recreation.
Please let us know if this resolves your issue. If your use case does not allow waiting in between recreation, we can look into a better solution.
Thank you,
Zhuolun

Hello @zhuolun-citrix ,
I have tested again and received the same result.
There might be an issue 🐞 with the Terraform resource “citrix_zone” or the Citrix DaaS backend 🚧.
After deploying and destroying via the pipeline about 20 times, we see around 20 zone GUIDs in DaaS that we cannot delete because the resource group is not present.
This is a demo environment for DaaS, and we can live with it. Could you clean up the old zones, or should we contact Citrix support?
Could you please perform the same test and give me feedback 👍
Test 1 Apply
resource "citrix_cloud_resource_location" "example-resource-location" {
  name = "mvd-100-P-azure"
}

# Wait for 10 minutes before creating the zone
resource "null_resource" "wait_10_minutes" {
  provisioner "local-exec" {
    command = "sleep 600"
  }
}
resource "citrix_zone" "example-zone" {
  resource_location_id = citrix_cloud_resource_location.example-resource-location.id
  depends_on           = [citrix_cloud_resource_location.example-resource-location, null_resource.wait_10_minutes]
}

###outcome
null_resource.wait_10_minutes: Creation complete after 10m0s [id=8357247440544287156]
citrix_zone.example-zone: Creating...
citrix_zone.example-zone: Creation complete after 1s [id=99dba58e-ada7-46b7-9216-e477240ce355]

Test 2 destroy
Warning: Attempting to delete Zone
│
│   with citrix_zone.example-zone,
│   on main.tf line 147, in resource "citrix_zone" "example-zone":
│  147: resource "citrix_zone" "example-zone" {
│
│ Zones and Cloud Connectors are managed only by Citrix Cloud. The requested zone will be deleted from terraform state but you will still need to manually delete these resources by logging into Citrix Cloud.

I can wait longer, but the zone is not being deleted, and in PowerShell, I see something like this.
Get-ConfigZone  -name mvd-100-P-azure

ControllerNames                           : {}
ControllerSids                            : {}
Description                               :
EnableHybridConnectivityForResourceLeases : False
EnableVdaConnectivityForResourceLeases    : False
ExternalUid                               : b9e3f8df-80c2-4018-b64d-466bf001577a
HasValidEdgeServers                       : False
IsHealthy                                 : True
IsPrimary                                 : False
LastStateChangeTimeInUtc                  : 03.10.2024 11:23:09
MetadataMap                               : {[ManagedBy, Terraform]}
Name                                      : mvd-100-P-azure
TenantId                                  :
Uid                                       : 99dba58e-ada7-46b7-9216-e477240ce355

@AlanCitrix
Could you please review and prioritize this together with #123? 🙏🏻

Hi @dimi4ik ,
When you try to destroy the zone, did you also remove the resource location behind it?
For a Citrix Cloud customer, when "Deleting" a zone with terraform, our provider will not actually do anything with the zone itself because the zone comes from the resource location behind it. terraform destroy will only remove the zone from state so that it will also remove the dependent resources of that zone. The zone will remain in your DaaS environment until you remove the resource location.
Please let us know if you can remove the zone from your DaaS environment by removing the resource location behind it.
Thank you,
Zhuolun

Hi @dimi4ik ,
Following up on this issue. Did you get the chance to try removing a zone by removing the resource location behind it?

@zhuolun-citrix
As previously mentioned, the Resource Location is immediately deleted when using Terraform. However, the Citrix DaaS Zone remains, either displayed as a name or as a GUID. I manually tried to install a new Cloud Connection on the tenant and then uninstall it after 2 hours. The Resource Location was immediately deleted, but the Citrix DaaS Zone remained. Based on these observations, the problem is most likely not with the Terraform Provider but with the backend.
A Citrix case has already been opened, but so far I have only received feedback from the first-level support. It is important that this ticket is now escalated to the backend support to properly investigate and resolve the problem.
To ensure a timely and effective solution, I suggest the following steps:
•	The current ticket should be escalated to the backend support.
•	The backend support should perform a thorough analysis of the cause as to why the Citrix DaaS Zone remains after the Resource Location is deleted.
•	A solution or workaround should be developed and implemented promptly.
•	Feedback on the current status and the next steps should be provided promptly.

Hello @dimi4ik, from our conversation in #123 you were not able to delete the Citrix Cloud Resource Location because it still had the Cloud Connectors. Were you able to workaround this by uninstalling the Connectors so that the Resource Location can be deleted? In general if there are any resources in the Zone that are not deleted, the Zone will not be cleaned up, see the documentation here: https://docs.citrix.com/en-us/citrix-daas/manage-deployment/zones.html#zone-deletion. This includes Connectors.

Did switching to .\cwcconnector.exe /uninstall /q fix the problem moving forward?
There is also a registry key that can be used to find the command which should be used for uninstall. It's the key used by Windows add/remove programs:
Start in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall and find the key with Display Name = "Citrix Cloud Connector", then get the value of  QuietUninstallString and use that for uninstallation. This will specify the cached installer from C:\Windows\Installer.

@AlanCitrix  🥇
With Citrix support, we could delete the old zones and fix the Cloud Connector installation and uninstallation. 💯 🥇
If we have any questions about the Terraform provider, should we always create a new issue or use email, forum? 🔢

If two people are creating something on the DaaS tenant simultaneously using Terraform, can errors occur or should it be possible?

Any problem with the provider you can post here, and then optionally loop in Citrix support like you did for this issue. Sometimes like in this case the problem is on the backend and not the provider, but we will do our best to assist.
To answer your question, there should be no issue doing multiple actions simultaneously as long as the names of objects do not clash between the two Terraform plans.

Closing this issue for now. Please reopen if you have further issues, or we can talk on #123 for enhancements to this flow.


Ghost listener SIGINT

Hello, I'm using ghost like npm module but I just notice ghost is removing all the listeners for SIGINT and SIGTERM so I need to listen that events too from process... Could some one explain why Ghost remove the listeners and how to solve this?
Thanks

Hi @gsantomesorry to hear you're having trouble. If you have questions about Ghost or need help, please head on over to slack - https://ghost.org/slack/ - and post in the #help channel. This is a bug tracker for ongoing development of the Ghost software, and we're not able to do support here!


Working on Futures rest_api for historical_trades over the weekend.

^ Will build off of the linear branch.

https://github.com/Igosuki/binance-rs-async/blob/master/src/client.rs
https://github.com/Igosuki/binance-rs-async/blob/master/src/api.rs
https://github.com/Igosuki/binance-rs-async/blob/master/src/config.rs
^ thoughts on using a similar structure for authentication?
IE specifically, shared client that signs stuff for whatever is received, and test/mainnet urls can be pulled from default config or passed in through custom config.

yo @traderlabs @sbusso wanna work with us on this instead of your binance fork: https://github.com/traderlabs/bybit-rs

also can we have async built in, PLEASE.
Idk how to create a project with async & sync at the same time though.

also can we have async built in, PLEASE.
Idk how to create a project with async & sync at the same time though.

Ok I'm fine not doing, will probably be slower & can just use threads.

Welcome!

^ Will build off of the linear branch.

linear branch is for USDT-M WebSocket client. The job will finish soon and this branch will be merged to main. Please create feature branch from main.

also can we have async built in, PLEASE.
Idk how to create a project with async & sync at the same time though.

This feature will be considered in a later version, but can not promise any priority. I focus on implementing all WebSocket&Restful API clients which are in a synchronized fashion for now.

I suggest this structure:
spot/
    ws.rs
    rest.rs
linear/
    ws.rs
    rest.rs


Add KafkaContainer implementation with SSL enabled

The idea would be to extend the current implementation to allow to customize the kafka container as much as possible.
SSL Implementation can be found in https://github.com/quarkus-qe/quarkus-test-suite/blob/main/messaging/kafka-streams-reactive-messaging/src/test/java/io/quarkus/ts/messaging/kafka/ssl/SslStrimziKafkaTestResource.java.

Kafka has a server.properties file that allow you to configure your kafka instance. The main idea of this ticket is to be able to set up your own custom Kafka through the Quarkus test Framework.
Main commits:
SSL: https://github.com/quarkus-qe/quarkus-test-suite/blob/main/messaging/kafka-streams-reactive-messaging/src/test/java/io/quarkus/ts/messaging/kafka/ssl/SslStrimziKafkaTestResource.java
OverwriteServerProperties: https://github.com/quarkus-qe/quarkus-test-suite/pull/231/files#diff-c956cdac94b49262e2ba359c6d451993047a1f81eab4f82730dfa19fc8e34445R14

There's also SASL config that should be considered for this feature.


Profiling output respects loglevel.

Description
"Profiling started" and other messages are now INFO loglevel and will respect the current loglevel.
Related issues
https://github.com/async-profiler/async-profiler/issues/960
Motivation and context
All messages should respect loglevel, "Profiling started" etc. messages did not.
How has this been tested?
With different loglevel parameters:
java ... -agentpath: ...,loglevel=info ...
Profiling started

java ... -agentpath: ...,loglevel=warn ...

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I'd argue that Profiler output should not respect loglevel.
Output and logs are two different streams. The former is where profiling results go to; results must be dumped regardless of the log level.
I think a better approach to the problem is to make "Profiler started" a log message, which it essentially is, with an exception of Java API, where this message is a valid response returned from execute method.

When testing, please verify all 3 ways to run profiler:

as an agent;
using asprof;
via Java API.

Simplified the approach, introduced a new LogWriter class to be used instead of FileWriter out(STDOUT_FILENO).
Tested as an agent, asprof and Java API.
❯ asprof start jps
Profiling started

❯ asprof start -L info jps
Profiling started

❯ asprof start -L warn jps

After this change, "Profiling started" message goes to asprof output. This is intended, but does not look perfect, given that asprof prints its own start/stop messages:
Profiling started
Profiling for 5 seconds
Done

I'm more are more inclined to believe this message is redundant and can be removed entirely except for the Java API call.


mian_joint.py is not avaliable.

Hi, could you tell me whether you only train the model in ytvos?

We use the model pre-trained on refcoco (the model are downloaded from ReferFormer) to train the model in ytvos.

Thanks.
So, you just finetune the model in the video datasets.
Have you tried the joint training?

Sorry. I have not tried joint training because the image-based dataset refcoco cannot support online training.


When "Add player numbers to party window" is selected, don't rewrite player name...

...instead, intercept the draw event for the party window itself to add it there - this will remove the need to sanitise player names elsewhere in the code

Looked into this, a bit too messy to do easily without a lot of effort and refactoring