Consumer when using Kafka Transport fails to start

I have successfully sent a message using NServiceBus configure with a Kafka Transport, but am unable to receive the message unless listening to Kafka outside of NServiceBus. The following code blows up in a console app:
`var endpointConfiguration = new EndpointConfiguration("Sales");
		var transport = endpointConfiguration.UseTransport<KafkaTransport>();
		transport.ConnectionString("<IP_ADDRESS>:9092");

		endpointConfiguration.UseSerialization<JsonSerializer>();
		endpointConfiguration.UsePersistence<InMemoryPersistence>();
		endpointConfiguration.SendFailedMessagesTo("error");
		endpointConfiguration.EnableInstallers();

		var endpointInstance = await Endpoint.Start(endpointConfiguration).ConfigureAwait(false);

		Console.WriteLine("Press Enter to exit...");
		Console.ReadLine();

`
The error indicated is: 2017-03-14 14:23:37.032 WARN  NServiceBus.Transport.Kafka.Receiving.MessagePump System.ComponentModel.Win32Exception (0x80004005): The directory name is invalid
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start()
at NServiceBus.Transport.Kafka.Receiving.QueueCreator.d__3.MoveNext()
I'm using NServiceBus 6.1.3 and the latest Kafka Transport library from NuGet.

Happy to see my first user.
The code had a bug, it must work in the latest nuget I have just uploaded.
Please tell me if it works.
Thanks for using.

Thank you for such a quick response.
The project starts with 0 errors/warnings now, but I am not getting the IHandleMessages<...> fired when a message is put on the bus. This did happen when using SqlTransport.

Could you try removing "sales" and creating a topic with the default service name?
Anyhow tomorrow morning I will try to see what's hapenning.

I'm not 100% clear on what you mean by the default service name? I'm actually using the NServiceBus sample lessons to work this out, so the actual program is "Sales.exe". I have this in my Producer, if it helps:
`var endpointConfiguration = new EndpointConfiguration("ClientUI");
		var transport = endpointConfiguration.UseTransport<KafkaTransport>();
		transport.ConnectionString("<IP_ADDRESS>:9092");

		var routing = transport.Routing();
		routing.RouteToEndpoint(typeof(C.PlaceOrder), "test");

		endpointConfiguration.UseSerialization<JsonSerializer>();
		endpointConfiguration.UsePersistence<InMemoryPersistence>();
		//endpointConfiguration.SendFailedMessagesTo("error");
		endpointConfiguration.SendOnly();
		endpointConfiguration.EnableInstallers();

		var endpointInstance = await Endpoint.Start(endpointConfiguration).ConfigureAwait(false);

		Console.Write("Press Enter to exit...");
		Console.ReadLine();

		await RunLoop(endpointInstance);

		await endpointInstance.Stop().ConfigureAwait(false);

`

I have been testing the examples in my machine and it works. I think the problem is here:
routing.RouteToEndpoint(typeof(C.PlaceOrder), "test"); <-- do you have an endpoint called test?
Which example are you using? there are a few of them.

You are correct, that code was from some other trial and error work. It does work now. I am getting warnings about offset removal whenever I get a message though:
2017-03-15 08:02:30.749 WARN  NServiceBus.Transports.Kafka.Connection.ConsumerHolder offset received cound not be removed from list
I'm not sure that is important and may be a residual side effect of earlier messages.
I'm very please to see this working and it is a big step for us. I appreciate your help!

Yes, I will set that message as info instead of warning.
Thanks for reporting the problem.


yeast 8.5.0

Main improvements in this PR:

Fixes:

combine glycolysis + gluconeogenesis as single KEGG pathway (PR #251)
rxn: corrects grRule of r_4590 (closes #252)
met: corrects name of s_1218 (closes #254)
saveYeastModel handles Unicode characters (PR #255)
indentation of yeastGEM.yml (contributes to #236)

Features:

memote as GitHub Action for pull requests (PR #162)
old subSystems changed to reaction annotation (in rxnMiriams or rxnKEGGpathways) (PR #253)

Chore:

update dependencies in *requirements.txt (PR #256)
minor changes in model file formatting due to updates in COBRA+RAVEN toolboxes (PR #253)

Refactor:

follow standard-GEM specifications (PR #257)
rename master and devel branches to main and develop (closes #258)

Also rename your local branches to main and develop:
git branch -m master main
git branch -m devel develop
git fetch origin
git branch -u origin/main main
git branch -u origin/develop develop

PR #257 and issue #258 should first be resolved
I hereby confirm that I have:

[x] Tested my code with all requirements for running the model
[x] Selected main as a target branch (top left drop-down menu)
[x] If needed, asked first in the Gitter chat room about this PR

It should be possible to just change the target branch in this PR without opening a new one?

Also, is the intention to resolve #11 as part of this release, or would it be better to postpone it?

I didn't close it manually, but I did just change the name of devel to develop, in accordance with #258. It might be that GitHub is at the moment still processing the name change, and will reopen it soon again to the newly named branch.
Re #11, this would take longer to resolve, so probably good to postpone to distribute as 2.5.1?

Oh, interesting side-effect or branch renaming.
Sure, it's okay reserve #11 for a subsequent release.


fix(40640) add missing notApplicableReason in protocol

Fixes #40640
protocol changes were missed in #37871
We will need to cherry pick this to release-4.0

Is there a protocol baseline that needs to be updated?

@typescript-bot cherry-pick this to release-4.0

For annoying reasons, the bot doesn't cherry-pick merged PRs

but... I've seen it do it...

Same! I have no idea how anything works. Maybe @weswigham knows.

Github GC's the ref if you take too long (and deleted the source branch), and once the ref is gone, it can't be picked anymore.

So I guess try not to delete the source branch immediately in the future and give that a shot - thanks @weswigham!

I don't believe I have 🤔

Maybe it's a difficulty across repos too.

That's usually fine... it looks like the pipeline never even triggered, so it seems like the comment didn't even get picked up. Lemme try...
@typescript-bot cherrypick this into release-4.0

🤷 github dropped the webhook, maybe? I dunno. Definitely triggered for me, and the accompanying logs seem fine, too (though maybe I should update the code for the latest octokit - there's some deprecation warnings).


Rust pipes test suite

Summary & Motivation
This sets up the initial integration with the dagster-pipes-tests suite. Most of the tests are skipped right now, they can be enabled incrementally.
How I Tested These Changes
cd libraries/pipes/implementations/rust
uv run pytest

Changelog
Ensure that an entry has been created in CHANGELOG.md outlining additions, deletions, and/or modifications.
See: keepachangelog.com

I wonder if it would be more appropriate to disable all tests in pipes.toml

That's a good point! I set all (skippable) tests to be skipped now.

the tests CLI args are not stabilized yet

That is good to know. I'll probably keep this PR in draft for a bit longer to work out how to deal with the clap dependency and to see if this setup works with one of the full tests

I think it's ok to start working on the tests. We will probably remove the --full flag (as it's almost always set to true) and do a bit changes here and there. It's not going to be a lot of changes. Just fyi.


Update running_moments.py

add function to normalize xarray dataset

@gregordecristoforo @sajidah-ahmed I believe this function should be moved to Sajidah's repo, since it deals with datasets produced by that code. do you agree?

Yes, I agree. https://github.com/sajidah-ahmed/cmod_functions is a much better place for it.

I think my concern earlier was that cmod_functions would end up having a dependency on fpp-analysis-tools. It seems like the function still relies on fpp-analysis-tool because it's using run_norm. The idea behind cmod_functions is that if someone wishes to just pull data from the MDS tree (without analysing time series according to the fpp), then they can use that without having to download an extra package. Since run_norm_ds is the only function that requires fpp-analysis-tools, I feel that it makes sense to keep it on fpp-analysis-tools with the caveat added to the doc string that one would need to download cmod-functions is they choose to work with experimental data. What do you both think?

@gregordecristoforo didn't you put run_norm is plasmapy recently? If so, wouldn't it make sense to incorporate into run_norm_ds?

That's a good point @sajidah-ahmed , I agree its nice to keep cmod-functions independent of fpp-analysis.
We can keep this function here then, if you are fine with that.
@auroradh I just made a small comment, if you resolve we cna merge

@Sajidah yes run_norm is available in plasmapy. If you don't mind having plasmapy as a dependency we could merge it here. However, keeping the number of dependencies low is always a good idea.


  This patch has no effect on the code built, but allows callers to turn on full warnings safely with clang.

Coverage decreased (-0.8%) to 95.585% when pulling 06575eb0a9115811d4cd2625b37f19f082c3667e on cyrusimap:cyrus into b333f3656d6a408fe38737982d854b80ea870803 on akheron:master.

For most versions of gcc and clang that I have seen, the inline directive prevents that warning, usually that warning is only omitted for static without inline.

Agreed with @ploxiln this should not be an issue if inline is enabled.  How are you configuring your libjansson?  Please post your jansson_config.h to a gist, in particular I'm interested in seeing what you have for #define JANSSON_INLINE.

This is our entire build script, with a fresh git checkout:
  git clean -f -x -d
  autoreconf -v -i
  ./configure --enable-silent-rules --prefix=$PREFIX
  make -j 8
  sudo make install

When I just tried that on my laptop now, I got a jansson_private_config.h but no jansson_config.h and my jansson_private_config.h did not match JANSSON_INLINE at all.
I will attempt to recreate the scenario and grab you the files from the build.

For most versions of gcc and clang that I have seen, the inline directive prevents that warning, usually that warning is only omitted for static without inline.

Sorry I missed this - perils of filing pull requests just before traveling!

src/jansson_config.h is created when ./configure succeeds.  If this file were not created then no part of jansson would compile.

Ahh right - it's the "src/" bit that I missed.  Ok, it's at https://gist.github.com/brong/af81aedc86b709ffaf1684c13d663ae0
I am trying to recreate by removing clang to build cyruslibs, then adding clang again before building cyrus.

Anndd.. there it is :)
/usr/local/cyruslibs-jansson-test/include/jansson.h:140:6: error: unused function 'json_decrefp' [-Werror,-Wunused-function]
void json_decrefp(json_t **json)

This happens when cyruslibs was built with gcc, and cyrus is being built with clang.

Your compiler/preprocessor is using static inline so this should result in the unused function being ignored.  Are you using older gcc or clang?
If needed I'm OK with adding JANSSON_ATTRS(unused) directly to the inline functions (this should explicitly suppress the warning for each function).  I'm not in favor of using the pragma method.


Final.py

Added .py file in week 7 of using python to interact with os

Per Coursera's Code of Conduct, solution for exercises should not be shared. I will be closing the pull request for now.
Thank you for the contribution though!


Start using mypy

As we are starting to annotate, we may as well start using that information to check for possible issues.

Yes, I saw the annotations. Mypy is a great tool, but accurate (and precise) annotations can get tedious. Aliases may help.


1.4.7 release

1.4.6 worked fine with the latest pyparsing, the only problem was in the tests where exception messages had changed.

Done!


bug: Argument of type 'FC' is not assignable to parameter of type 'ComponentType

Describe the bug
Argument of type 'FC<BlockProps>' is not assignable to parameter of type 'ComponentType<MillionProps>'
This error appears when using TS with the library.
type BlockProps = {
  element: string[];
  index: number;
  setAlertDialogImage: Dispatch<SetStateAction<string>>;
  onOpen: () => void
}

const ColumnBlockComponent: FC<BlockProps> = ({ element, index, setAlertDialogImage, onOpen }) => {
  return (
    <Box
      key={index}
      wordBreak="break-word"
      textAlign="left"
      alignSelf="flex-start"
    >
      <HStack alignItems="top">
        <Text color="gray">{element[2]}</Text>
        <Text color={element[3]}>{element[1]}</Text>
        <Box flex="1" wordBreak="break-word">
          <Text>{element[0]}</Text>
        </Box>
      </HStack>
      {element[4] !== '' && (
        <ChakraImage
          rounded="0.2rem"
          width="80%"
          onClick={() => {
            setAlertDialogImage(element[4])
            onOpen()
          }}
          src={element[4]}
        />
      )}
    </Box>
  )
}

const ColumnBlock = block(ColumnBlockComponent)

leads to the error Argument of type 'FC<BlockProps>' is not assignable to parameter of type 'ComponentType<MillionProps>'
As you can see, the documentation has been followed completely, but the error appears nonetheless.
The full error is:
Argument of type 'FC<BlockProps>' is not assignable to parameter of type 'ComponentType<MillionProps>'. ts(2345)
  Type 'FunctionComponent<BlockProps>' is not assignable to type 'FunctionComponent<MillionProps>'.
    Types of property 'propTypes' are incompatible.
      Type 'WeakValidationMap<BlockProps>' is not assignable to type 'WeakValidationMap<MillionProps>'.
        Property 'element' is incompatible with index signature.
          Type 'Validator<string[]>' is not assignable to type 'Validator<string | number | bigint | boolean | symbol | Block>'.
            Type 'string[]' is not assignable to type 'string | number | bigint | boolean | symbol | Block'.

Hey @kul-sudo, thank you for this. This seems to be a typing issue though, we'll take a look at it to get it sorted. Can you maybe join the Discord server?

https://million.dev/chat

Hey @kul-sudo, thank you for this. This seems to be a typing issue though, we'll take a look at it to get it sorted. Can you maybe join the Discord server?

Yeah, I can join, of course.

Also, the full error is
Argument of type 'FC<BlockProps>' is not assignable to parameter of type 'ComponentType<MillionProps>'. ts(2345)
  Type 'FunctionComponent<BlockProps>' is not assignable to type 'FunctionComponent<MillionProps>'.
    Types of property 'propTypes' are incompatible.
      Type 'WeakValidationMap<BlockProps>' is not assignable to type 'WeakValidationMap<MillionProps>'.
        Property 'element' is incompatible with index signature.
          Type 'Validator<string[]>' is not assignable to type 'Validator<string | number | bigint | boolean | symbol | Block>'.
            Type 'string[]' is not assignable to type 'string | number | bigint | boolean | symbol | Block'.

Hey @kul-sudo, thank you for this. This seems to be a typing issue though, we'll take a look at it to get it sorted. Can you maybe join the Discord server?

Any updates?

Hey @kul-sudo, thank you for this. This seems to be a typing issue though, we'll take a look at it to get it sorted. Can you maybe join the Discord server?

I spoke with the team already, it'll be sorted out soon.

Hey there, which version are you using and where are you importing block from?

Hey there, which version are you using and where are you importing block from?

The absolutely latest version. I import it from million/react

Closing due to having creating a new more precise issue.
#475

Closing due to having creating a new more precise issue.
#475


[BUG]: Unable to register

There is some issue with registering as it's showing 405 Method Not Allowed.
https://github.com/user-attachments/assets/25a50cc6-bac0-4b23-b4ed-9006181e8739

@soham0005 assign me this issue